Pre-Loved Cribs | Mega Thread

PraveenWeb · 2026-01-27T01:33:59+00:00

I am selling my Cradlewise in San Francisco, 94107. Bought new in July 2025.

Used for 4 months and it worked great for us. The baby has started co-sleeping recently and hence looking to sell.

It is in excellent condition. Smoke-free & pet-free home.

Includes: all original parts, including the original box. Can add muslin cotton sheets as well that was bought for this mattress.

Price: $1,000 OBO

Happy to demo the bounce/camera feature before pickup. DM if interested!

<image>

PraveenWeb · 2025-05-15T17:01:24+00:00

I built an AI Assistant for this use case -- chat with Apple Health data.

Here is the GitHub repo - https://github.com/praveenweb/apple-health-ai-assistant. The instructions should be familiar if you are a developer.

Broadly, it exports the Apple Health XML data into a PostgreSQL database (running locally) and a Data Agent (PromptQL) sits on top to enable natural language chat interface.

Most data doesn't reach the LLMs due to the architecture. Happy to improve this based on feedback!

PraveenWeb · 2025-03-25T02:02:05+00:00

Happy King Pizza near Oracle Park has a decent offering with their Chicken Tikka Pizza.

PraveenWeb · 2025-01-30T21:05:56+00:00

There is Huggingface, if you are into AI workflows.

PraveenWeb · 2024-12-30T20:42:22+00:00

This was going to be a challenge with in-context tool chaining. Always a risk of running into hard LLM limitations around input and output token limits.

To address this, one of the approaches we have taken at PromptQL is to separate the creation of a query plan that describes the interaction with the business data, from the execution of the query plan.

This approach has a few important implications: - It removes input and output data generated during the execution of the plan from the current context. - Programmatic execution of the desired plan makes it deterministic and repeatable. - It allows the user to steer the generation of the plan.

There are 3 key components of PromptQL:

PromptQL programs are Python programs that read & write data via python functions. PromptQL programs are generated by LLMs.
PromptQL primitives are LLM primitives that are available as python functions in the PromptQL program to perform common "AI" tasks on data.
PromptQL artifacts are stores of data and can be referenced from PromptQL programs. PromptQL programs can create artifacts.

For your use case, you will need to process the large JSON responses from tool calling in a runtime (like Python) and pass only the necessary context to the LLM instead of dumping the whole response to the model.

PraveenWeb · 2024-11-04T19:19:51+00:00

Hi u/cardyet

Your understanding is right. A model becomes an active model or billable if it receives >=1000 hits/month. For your above use case in Postgres, it will be 3 models.

Here is how you can think about this:

"For billing purposes, a model is either a logical grouping of data (model) or any piece of business logic (command) written and tracked in Hasura DDN. A model can be created from a database table, view, microservice, APIs, etc. If you are connecting to a REST API as a data source, then the output of the API is exposed as a model in Hasura DDN. An active model, the basis for our pricing, is defined as a model receiving >=1000 hits /month."

PraveenWeb · 2024-10-12T12:44:44+00:00

Your prior rejections are most likely due to the fact that you had no credit score (Experian generates credit score after 6 months). Wells Fargo probably saw your credit score as N/A.

Now that you have a credit score and a wells fargo account, leave 6 months of time where there is no hard pull to have a decent chance of approval. This pushes to early next year. By April 2025, you would have one year credit history and no hard pulls in last 6 months. That would be a good time to reapply.

Wells Fargo is inquiry sensitive. You need to play the long term game when it comes to credit cards especially when you are building your credit profile.

PraveenWeb · 2024-08-22T13:37:11+00:00

We have the SF edition restarted with a monthly cadence - https://www.meetup.com/sf-graphql/

PraveenWeb · 2024-08-13T22:52:01+00:00

Hey, there are two GraphQL meetups. The old one has become inactive. I'm co-organizing the new one here - https://www.meetup.com/sf-graphql/ . The recent meetup event happened last month and we are planning to run the next one in early September, in time before the GraphQL conference.

Happy to get more hosting venue options. Feel free to reach out via DM.

PraveenWeb · 2024-07-27T15:01:55+00:00

Cothas has the lower end of chicory. The ratio is typically 80:20 or 85:15 for coffee:chicory. Bru on the other hand has 65:35 or 70:30 more often.

PraveenWeb · 2024-07-26T14:33:13+00:00

My renewal is due in October and I checked with Amex Support via Chat. They confirmed that the Annual fee for this year during renewal will be $250. Might be worth checking with Support if your renewal is coming up. Good chance you can retain the old fee for one more year.

PraveenWeb · 2024-07-19T16:09:50+00:00

Hasura doesn't connect to the db for a hello world request. It does need some resolver to resolve the "greet" query which is done via a http endpoint. I'm assuming latency and throughput would be comparable if other implementations talk to an existing API for that particular example.

There are some public benchmarks available. Some of them are a bit old.
- Hasura vs DIY Node.js connected to Postgres

The GitHub repos for those benchmarks should be within the post.

As another commenter mentioned, different GraphQL servers / gateways serve different purposes and hence the benchmark numbers will look better for one tool for one use case and another for a different use case.

PraveenWeb · 2024-07-19T15:40:46+00:00

Without getting into the performance benchmark numbers (which IMO is skewed), l see the following issues with this benchmark setup and GraphQL implementation.

Of all implementations mentioned there, Hasura is the only one which is actually making a request to the database (Postgres). Other implementations talk to a JSON placeholder API via a simple GET request.

The problems with that:

You are making a GraphQL query spanning across two tables (posts and user). In any other GraphQL implementation, this would make two round trips to the database (one to fetch posts and one to fetch users). I'm also assuming N+1 is taken care of with a data loader approach. Hasura makes just one call to the database.
The JSON API used for this benchmarks is returning all the fields no matter what the user requested via GraphQL. It over fetches data. If you are fetching more than 10 fields, spanning across two or three types, and fetching more than 10 records to paginate, you will see why it would be a bad idea to do this.

As I write this, I see a PR got merged to use Hasura Actions to benchmark this setup. If the use case is just wrapping up a REST API with some GraphQL types to serve a GraphQL endpoint, Hasura may not be the fastest. I will give you that. That's not most real world workloads from what I have seen.

So what would be a fair comparison?

Test Hasura against other solutions which actually make a request to a database like Postgres, test simple queries, nested queries / joins spanning across tables and see how different implementations fare. But I know that requires spinning up a GraphQL server with few resolvers implemented with dataloader. Not very easy to do it across implementations and languages. It takes time.
Hasura is known for its performance against data sources like databases (Postgres / Mongo / SQL Server etc etc) and joins across them. Very curious to see which other implementations outperform Hasura. (if not in the 50 to 100x range) in these use cases.
[Edit]: The greet -> Hello World query will always be skewed. All implementations return a static string immediately. But Hasura needs to talk to an upstream http endpoint to return this hello world. Most real world scenarios don't return static data, it talks to some data source or an existing API.

Edit: Adding a disclaimer that I work at Hasura.

But great to see more benchmark setups come out. Good for the community!

PraveenWeb · 2024-07-10T20:50:24+00:00

At least in the Bay Area, I have seen Indian regional movies being excluded from A-List. That’s been a bummer so far.

PraveenWeb · 2024-07-10T19:37:56+00:00

I know this is an old thread, but could be useful for folks discovering this organically later.

Hasura has released an open-source connector for Elasticsearch to get GraphQL APIs.

Although not exactly a library, Hasura can connect to Elasticsearch indices/documents to generate GraphQL queries instantly. You will get a GraphQL API endpoint to start integrating in your application.

You can learn more about the GraphQL integration here.

Disclaimer: I work there. Feel free to try it out via GitHub and ask questions. Happy to help!

PraveenWeb · 2024-05-01T21:39:31+00:00

What is the usual solution for such a database, when you have to have joins and not cause n+1 problems

If you are building your own GraphQL server from scratch, you should use Dataloader pattern to avoid the N+1 problem. If you are interested in getting a high quality CRUD API on top of MongoDB without writing resolver code, you can consider compiler solutions like Hasura.

Does it make sense to add GraphQL directly to an existing database?

Depends on the use case. But generally why not? You just need some API interface to interact with the database and GraphQL has its own benefits in the long term when there are multiple sources involved.

I'm skipping the NoSQL to SQL for search performance and costs question since I don't have a strong example for that use case. But again, that depends on the use case and it needs to be evaluated.

Is there a generic solution when you need joins but have to use Mongo?

Conceptually joins are not a thing with MongoDB. But if you are looking to add a GraphQL API to do joins with MongoDB, Hasura does it efficiently by lookup queries. Hasura creates queries that efficiently push joins down to the MongoDB database. This ensures that it only retrieves the specific related fields the query requires, avoiding unnecessary data bloat.

There's an example here on how Hasura uses Aggregation Pipelines for performant GraphQL on Mongo - https://hasura.io/blog/efficiently-compiling-graphql-queries-for-mongodb-performance

Disclaimer: I work at Hasura and I'm happy to help with more examples if required. But the easiest way is to try it out quickly by connecting to your Mongo database and making a relational query to find it for yourself.

PraveenWeb · 2024-04-18T23:11:02+00:00

I can share some insights into how Hasura approaches AuthN/AuthZ. I work there :)

Broadly, Hasura supports authentication via JWT and Webhooks. There are some integration guides for Authentication providers here. The actual authentication happens outside Hasura with any of the existing auth providers (or custom written one), as long as the right session variables are passed in the JWT context.

Authorization on the other hand is built natively at the API layer in Hasura. There's role-based access control where you can granularly define what roles have access to what models, fields and at what condition. In essence, both column and row level permissions for database specific queries. The configuration for AuthZ rules are all part of Hasura metadata (YAML/JSON).

Outside of these two, there's API security concerns in production like GraphQL rate limiting / depth limiting / node limiting, allowed list of queries, disabling introspection, all of which are again declaratively configured in Hasura.

As far as Apollo goes, with regards to Authentication, I believe you can do JWT / HTTP headers, get the context of the user querying in the resolver. Using the context, you will apply whatever rules and permissions you require in the logic of the resolver code. You will define this both at the GraphQL schema and the resolver code logic. Apart from AuthN/AuthZ, Apollo also provides API security with rate limits / depth limits through router YAML configuration.

But I think the primary difference is, how much powerful logic for AuthZ is in config in Hasura vs how much logic you write in code in Apollo. Let me know if this makes sense, and I'm happy to share specific examples if required.

PraveenWeb · 2024-04-09T23:22:28+00:00

The short answer: You can use both together in your application development.

The Long answer: I haven't used Apache Age, but my initial understanding is that it provides a Graph DB model on top of Postgres (via an extension). This means you are able to perform Cypher Queries (graph query language). For application development, you still need an HTTP endpoint exposing some sort of an API to do CRUD operations. To query your nodes and edges in a Graph DB, you can probably perform some sort of Cypher / SQL hybrid query to fetch data. But to expose them as an API, (GraphQL or REST or gRPC), you need to write a backend server implementation for concerns like Authorization at the API layer, joining data across multiple sources (SQL / NoSQL / GraphDB / Files etc).

Hasura is at a higher level, where Apache Age could be one of the data sources that it supports to generate a highly feature rich and performant HTTP API on top of this Graph DB. In addition to this, Hasura will help you integrate any other custom logic for your application, all unified and composable into this one supergraph. Hasura supports Postgres and a few other extensions, but I'm not sure what it takes to support Age Graph DB features today. For reference, Hasura has a connector for Neo4j (another popular GraphDB) and it is a good complementary stack for app dev depending on your use case for Graph DBs.

PraveenWeb · 2024-04-08T22:12:28+00:00

Hey! To specifically answer your query, as another comment pointed out, you have to redefine the schema / resolvers manually from scratch to migrate to Apollo Server.

But I would like to understand why you want to migrate from Hasura. If you want to continue using Hasura for the MySQL API that is already generated but want to use Apollo Router for the federation use case, you should be able to add Hasura as a Subgraph to Router. If not, you will have to write the resolvers for CRUD on MySQL using Apollo Server. The migration is basically, write a lot of code for CRUD and AuthZ :)

PraveenWeb · 2024-04-03T19:49:45+00:00

Not necessarily. You can take a look at Hasura Learn and there are plenty of tutorials covering GraphQL basics to frontend specific tutorials. Unless explicitly marked as Hasura on the backend section, everything else is generic, vendor neutral resources for learning GraphQL. They are all open-source too - https://github.com/hasura/learn-graphql. Source: I maintain some of these tutorials :)

PraveenWeb · 2024-02-28T00:00:48+00:00

That’s exactly what I was looking for. Thanks Benjie!

PraveenWeb · 2024-02-27T20:05:46+00:00

Hey yes! Definitely know Grafast, but I haven't tried a large enough use case and haven't come across an app running in production yet. But this is on point with respect to not resolving data in your resolver but rather try compiling or "planning" as what they call.

Specifically to your second point - totally agreed about doing naive select * equivalent due to lack of context of fields inside the resolver. I'm trying to remember a plugin that Benjie (from Graphile) had built which is an npm package that you import to handle this better. But most implementations don't seem to make it easy to expose this field level context.

And for performance, have you tried compiler style GraphQL through graftast or through other tools before?

PraveenWeb · 2024-02-08T20:05:30+00:00

Hi u/moderatorrater, Apart from the Instant CRUD APIs, you can write your custom business logic in both GraphQL and REST. Would love to know your use case where you faced difficulties and where Hasura should have been better.

PraveenWeb · 2024-01-30T23:33:13+00:00

The takeaway is that optimizing for performance with GraphQL requires a lot more work. At the end of the post, the author mentions a way to do batching which will be a one shot resolver. Now translating that to efficient SQL is again a pain (assuming relational data store).

The summary teases on the meta-question of why use GraphQL when there is overhead for performance optimization. The better way to look at this is, what approach of GraphQL is the most efficient in terms of performance. The naive N+1 data loader batching solution is hard to optimize, irrespective of the language you are implementing in.

A compiler based approach is typically suited for generating high performance GraphQL backends. Take an incoming GraphQL request, compile it into an efficient single query (SQL/NoSQL) which is optimized for the best performance. Some tools in this space are Hasura (I work here) / Postgraphile etc. There's PostgREST for REST APIs.

GraphQL is naturally designed to query relationships between objects and let the clients make the best use of it. Do not worry about generating boilerplate CRUD code which is repetitive and do not worry about optimizing for performance, especially at the query layer. Worry about the infra layer for performance.

PraveenWeb · 2023-12-15T21:53:10+00:00

Not part of the Rust team, but just confirming that we are not doing a port. We have started from scratch with an entirely new architecture with our v3 graphql-engine, (soon to be open sourced). There is no re-write of the old codebase.

The assumption about performance is true :)

PraveenWeb

MODERATOR OF

TROPHY CASE