▲ | ramon156 3 days ago | |
Interesting! have u taken a look at safeql? https://safeql.dev/ I'm personally not a fan of query builders for SQL. it's already a defined language, why are we trying to move away from queries? On top of that SafeQL is only a dev dependency, there's no abstraction. it gets ran through any query client you want | ||
▲ | ryanrasti 2 days ago | parent [-] | |
Thanks for the great points and link to SafeQL! I'm a big fan of its approach to bringing type safety to raw SQL strings. For static queries, it's a fantastic solution. My take is that while "Just use SQL" is healthy pushback against heavy ORMs, a good query builder solves two fundamental problems that raw SQL can't in the application context: 1. Dynamic composition: A query builder is the macro system that SQL is missing. The moment you need to build a query programatically (e.g., conditional filters or joins) you're left with messy/unsafe string concatenation 2. Handling Relations (and other common patterns): Using raw SQL, a complex query with JOINs returns a flat list of rows that now becomes the application's job to properly denormalize. It greatly reduces cognitive load to think in terms of relations, not just join conditions. Again, showing is stronger than telling. To illustrate, I'd urge you to go through the first couple of examples in the playground and think about how you'd express them (e.g., the composability of the "example1" query) in something like SafeQL: https://typegres.com/play/ |