4 ms·

I'm sure a lot of effort went into this, but I would rather raw dog my database layer with node-postgres/postgres.js and zod. The decorator heavy implementation

I'm sure a lot of effort went into this, but I would rather raw dog my database layer with node-postgres/postgres.js and zod. The decorator heavy implementation is visually very busy. Also, I would not consider any SQL toolkit for serious use unless it comes with a sufficiently competent code generation accompaniment.

plopz 2y ago
My feelings are similar and I cringe every time I see a "typesafe" db interface that doesn't run time validate the data.
- webda2l 2y ago
  I created https://github.com/a2lix/schemql https://github.com/a2lix/schemql that maybe could fit your demand.
- lerp-io 2y ago
  typescript people want types on everything cuz it feels good that way.
  - nikisweeting 2y ago
    Also it allows AI tools in IDEs like Cursor to work a lot more effectivley because they can leverage type/lint errors to make sure suggestions are correct on the first try.
- jadbox 2y ago
  What do you use for runtime? I've used pgtyped in the past and it does a good job at taking raw SQL and generating the return types from runtime: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
- bluepnume 2y ago
  Runtime validate at the database boundary? Isn't it better to just do runtime validation at the api boundary instead? Then any of the types that make it into the database should be mostly guaranteed by TS (and of course, whatever types are enforced by the database schema itself).
retropragma 2y ago
Manual type declarations are error prone, tedious, and subject to drift. Meanwhile, query builders are clumsy and sometimes limiting or buggy, so I don't blame you for betting on raw SQL. I'm building a middle ground of sorts. Raw SQL (or PL/pgSQL which can be quite powerful) with generated, type-safe client "bindings" (TypeScript functions). It also includes "declarative SQL schema" (instantly update the schema of your dev DB on file save). Generated migrations and "seed scripts" are also on the roadmap. If any of that interests you, check it out (https://github.com/pg-nano/pg-nano https://github.com/pg-nano/pg-nano). I would also love to discuss it with whoever's reading this on Discord (@aleclarson).

plopz 2y ago

My feelings are similar and I cringe every time I see a "typesafe" db interface that doesn't run time validate the data.

webda2l 2y ago
I created https://github.com/a2lix/schemql https://github.com/a2lix/schemql that maybe could fit your demand.
lerp-io 2y ago
typescript people want types on everything cuz it feels good that way.
- nikisweeting 2y ago
  Also it allows AI tools in IDEs like Cursor to work a lot more effectivley because they can leverage type/lint errors to make sure suggestions are correct on the first try.
jadbox 2y ago
What do you use for runtime? I've used pgtyped in the past and it does a good job at taking raw SQL and generating the return types from runtime: https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
bluepnume 2y ago
Runtime validate at the database boundary? Isn't it better to just do runtime validation at the api boundary instead? Then any of the types that make it into the database should be mostly guaranteed by TS (and of course, whatever types are enforced by the database schema itself).

retropragma 2y ago

Manual type declarations are error prone, tedious, and subject to drift. Meanwhile, query builders are clumsy and sometimes limiting or buggy, so I don't blame you for betting on raw SQL. I'm building a middle ground of sorts. Raw SQL (or PL/pgSQL which can be quite powerful) with generated, type-safe client "bindings" (TypeScript functions). It also includes "declarative SQL schema" (instantly update the schema of your dev DB on file save). Generated migrations and "seed scripts" are also on the roadmap. If any of that interests you, check it out (https://github.com/pg-nano/pg-nano https://github.com/pg-nano/pg-nano). I would also love to discuss it with whoever's reading this on Discord (@aleclarson).