I've given up on trying to wrap SQL in any way. Too many bad experiences. I just use it as-is with fully dynamic types. My go-to stack is Postgres + NodeJS, no Typescript. No query builders, no ORMs especially. Postgres is meant to be used on its own with a minimal client lib. It works beautifully.
And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I get to do full TDD often. And the bugs I catch are never due to mishandled types.
> And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests.
I'm a type-safety kind of guy, but this argument (that time spent "fighting" the type system) is better spent writing tests when it comes to DB queries, has me very very curious. Would love others' opinions/experience on this!
Small clarification, the tests aren't on the DB queries alone. It's a full flow on a test backend, like it calls /editProfile to name a user "Bob" then calls /getProfile, and it expects the response to have `name: "Bob"`. It'll probably fail if I mess up a type and get "undefined," but it's also testing much more than that.
Ah, in that case, I'm much less interested :D , because that would mean that you let the untypedness of the DB queries propagate through pretty much the entire codebase.
And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I get to do full TDD often. And the bugs I catch are never due to mishandled types.