Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

github.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#81

Post by kevsim »

bijection wrote: post #23
renke1 wrote: post #10

Looks pretty cool. What I really want though is a library that let's me write plain SQL queries which are then mapped into nested objects in a smart way without too much manual work (I know Postgres can do JSON stuff, but the queries look pretty complicated for what little they actually do). Say `SELECT * FROM user LEFT JOIN post ON user.id = post.id` would be mapped to `[{userId: 1, name: renke1, posts: [{postId: 2,…

If you were willing to give up a bit of magic, you could probably build this as a thin layer over PgTyped. The API could be something like this: Query.sql SELECT * FROM user LEFT JOIN post ON user.id = post.id Application.ts const results = await Query() const nested = nest(results, { parentFields: ['userId', 'name'], childFields: ['postId', 'title'], childName: 'posts' ) If you wanted, you wouldn't really have to sp…

> but after a point it doesn't make sense to write queries that return so much duplicate data anyway

This is what I'm constantly wondering. At what point does it stop being good to return the user table results again and again and just switch to, for example, an IN query to get the posts?

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#82

Post by rhlsthrm »

eyelidlessness wrote: post #59
chrischen wrote: post #26

Earlier quoted context omitted.

See https://typeorm.io/#/

I mean no disrespect to the TypeORM author(s), but I was burned several times by unexpected behavior that resulted in serious data integrity issues. I would caution that anyone adopting this library test any usage heavily, especially anything to do with relations

What version did you use? Have the issues been raised and addressed? Curious because I am using it in production and now I'm worried. Would love more information about reproducing the issues as well.

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#83

Post by gmac »

mekster wrote: post #80
gmac wrote: post #74

Earlier quoted context omitted.

I’m not exactly sure what you’re getting at here. The whole point of this library is that one call = one predictable query, and the SQL it generates is certainly no more convoluted than required to produce the desired result.

What was so hard to grasp with my comment? If your query was meant to say, SELECT * FROM users JOIN posts ON posts.userId = users.id the ORM has so many unnecessary characters just to get to this straight forward SQL and you have to learn how to make sure the way you write will generate the SQL that you want that uses the proper index everytime you change framework is just something I wouldn't do. I didn't say the SQ…

The problem is that there's no obvious, simple way to bring the results of this query, structured and typed appropriately (with posts nested inside users), into our running code.

So we have to choose what we think is the least-worst compromise.

Since I wrote the library I am obviously anything but impartial, but the compromise I outlined above is one I'm pretty happy with (and it's much easier to read if you add a few line breaks). It's a bit noisier than your JOIN query, but for the price of that noise you get type safety and an appropriate JSON structure for the result.

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#84

Post by Nelkins »

rubber_duck wrote: post #36
the_duke wrote: post #28

There are some similar projects, like sqlx [1] for Rust. My problem with these is that they don't help to solve the actually hard problems. While nice to have, preventing bugs with static SQL is usually easy to do by writing a few tests. Most of the SQL related bugs I have encountered were due to queries with dynamic/conditional joins, filters and sorting - and almost every project using a database needs those. Appro…

> preventing bugs with static SQL is usually easy to do by writing a few tests I've heard the same argument about TypeScript vs JavaScript and it's something dynamic typing proponents often say but in practice I find immense value in having the types autocompleted and checked in the editor - and I've worked plenty on both sides, current project is substantial RoR codebase, I've worked with Python and node.js backends…

F# also has support for analyzers that can achieve similar functionality in case you don't want to take a dependency on a type provider.

https://github.com/Zaid-Ajaj/Npgsql.FSharp.Analyzer

https://github.com/aaronpowell/FSharp.CosmosDb#fsharpcosmosd...

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#85

Post by lioeters »

mikewhy wrote: post #52
Vinnl wrote: post #45

Lots of comments here about similar projects in a different language, but the fact that this targets TypeScript is explicitly what makes it interesting to me. Using regular Javascript database libraries, even ones that have type definitions, require a lot of double typing. I've been relatively satisfied with TypeORM, but one thing that's been a hurdle for me to some extent is its reliance on experimental decorators,…

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.

I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup.

Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow.

Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be extensible - for better or worse.

For example, Babel macros ¹ is an interesting concept, using the language to extend the language during compile time.

To bring it back to the topic at hand (PgTyped, Typesafe SQL) - one thing that I'd like to see in TSC is a way to output type definitions (either inlined metadata or external JSON schema), to be consumed for run-time type checking. That would "complete the circle" for me.

TypeScript "compiler plugins" seem to be on the roadmap, or at least under consideration ². Some may see that as opening a proverbial can of worms, down a similar road to Babel. I wouldn't disagree, but it'd be so useful!

¹ https://github.com/kentcdodds/babel-plugin-macros

² https://github.com/Microsoft/TypeScript/issues/16607

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#86

Post by mikewhy »

Vinnl wrote: post #77
mikewhy wrote: post #52

Earlier quoted context omitted.

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.

Would be interesting to hear what about it it is that makes it a bad thing - unless it's just the fact that it's a single project?

I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, and don't have to change anything, or worry about compatibility between things. And I'm starting to all the babel-preset-* packages have just created a bunch of busywork for the maintainers.

Then there's the issue of tooling requiring Babel. react-hot-loader should not require Babel. graphql tooling should not require Babel.

I'd argue when you're knee-deep in Babel, you're no longer writing JS, you're writing BabelScript. Only your BS capabilities are different than Jane's BS capabilities, which are also different from Bob's setup over there.

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#87

Post by mikewhy »

lioeters wrote: post #85
mikewhy wrote: post #52

Earlier quoted context omitted.

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.

I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup. Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow. Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be ex…

Oh agreed on all fronts :). Being able to add plugins is amazing, and there have been times I've almost added ttypescript for its plugin support. But then I remember the road that leads you down, and avoid it.

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#88

Post by alde »

lioeters wrote: post #85
mikewhy wrote: post #52

Earlier quoted context omitted.

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.

I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup. Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow. Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be ex…

You might find io-ts [1] interesting. It allows to write composable parsers that do both runtime checks and have correct result types.

Opt-in runtime checks for SQL queries are also on the roadmap for PgTyped. You are welcome to open an issue to track our progress there if you think this feature will be useful for you.

[1] https://github.com/gcanti/io-ts

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#89

Post by lioeters »

alde wrote: post #88
lioeters wrote: post #85

Earlier quoted context omitted.

I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup. Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow. Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be ex…

You might find io-ts [1] interesting. It allows to write composable parsers that do both runtime checks and have correct result types. Opt-in runtime checks for SQL queries are also on the roadmap for PgTyped. You are welcome to open an issue to track our progress there if you think this feature will be useful for you. [1] https://github.com/gcanti/io-ts

Thank you - yes, I've dabbled with io-ts, though I'm still learning how to wield its power.

> Opt-in runtime checks for SQL queries

Ah right, I do see in the repo for PgTyped that it's on the roadmap. That does sound useful!

I'm hoping that one of these days, TypeScript will support a more generic runtime type check, somehow closer to the language/TSC-level rather than userland libraries, plugins/transforms, or a parallel compiler/build step.

At the moment, I use a fork of typescript-json-schema ¹ for my purposes.

¹ https://github.com/YousefED/typescript-json-schema

Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

#90

Post by Vinnl »

mikewhy wrote: post #86
Vinnl wrote: post #77

Earlier quoted context omitted.

Would be interesting to hear what about it it is that makes it a bad thing - unless it's just the fact that it's a single project?

I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, and don't have to change anything, or worry about compatibility between things. And I'm starting to all the babel-preset-* packages have just created a bunch of busywork for the maintainers. Then there's the issue of tooling requiring Babel. react-hot-loader sho…

Ah, I hear you - I'm not a fan of enabling a bunch of arbitrary Babel plugins either. But many metaframeworks (Next.js, Create React App) use Babel behind the scenes and use its TypeScript plugin for out-of-the-box TypeScript support. That's very useful, as long as the libraries you use don't use any of the Babel-incompatible features - which is most of the time, but not for TypeORM.

So yes, it's exactly because I don't want to be configuring all kinds of language support for my projects that I'd recommend being able to work with (plain!) Babel with a TypeScript plugin.

Post reply on HN