Live data from Hacker News

Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres

github.com

71–80 of 90 posts

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

#71

I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at lea…

Can't say enough good things about slonik. Have been using it in production for a while now and I love it. For people like me who believe "abstracting away SQL" is a mistake, but still want protections against SQL injections and a nice API, slonik is a godsend.

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

#72
post #69

I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at lea…

I wonder if the JIT compiling will work asynchronously - from the readme it's getting the types from the live database schema.

Its actually doing the with what looks like a custom async messaging queu. Pretty cool.

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

#73
post #48

Earlier quoted context omitted.

Zapatos author here. Yes, it does. But for most of what you’d use an ORM for, you probably won’t need custom queries.

Hey I’m not sure this is the best venue, but I’m trying to make the case for getting my org off of sequelize, and your library is right in line with my goals. The hardest sell is going to be publicly visible test coverage. Would you welcome a dedicated effort from an early adopter to introduce tests?

Yes, that would be very welcome. I suggest you keep me in the loop from the start to make sure we end up with something we’re both happy with.

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

#74
post #68
post #49

Earlier quoted context omitted.

Zapatos can generate the hairy JSON stuff for you, including lateral joins that are equivalent to your example query, which would be: const result = await db.select(‘user’, db.all, { lateral: { posts: db.select(‘post’, { userId: db.parent(‘id’) }) } }).run(pool); And result will have the structure you asked for, and be automatically typed as such. (Sorry, can’t manage helpful indentation from my phone). See: https://…

I just don't get why people write queries like that in a convoluted way which is hard to decipher and possibly optimize with so many noises whose knowledge becomes useless on the next language/framework of choice than a straight forward SQL whose knowledge can live for decades.

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.

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

#75

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

Yes. My brief experience with TypeORM made me feel like it was written by people who really understand TypeScript, but maybe don’t understand SQL so well. It was a brief experience because I quickly lost trust in it.

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

#76
post #38

Earlier quoted context omitted.

ORMs like Diesel are definitely very useful. The problem I have with them is that their ORM abstraction often leaks. Fixing these abstraction leaks is a hard problem [1]. Ofc, there has been attempts to reconcile relational DBs with OOP like languages, but they are not very popular. [2] PgTyped and some similar libs try to solve a simpler problem (typing static queries) and can be used to build more complex solutions…

I may just not have enough context on the issue, but i've not had significant issues with SqlAlchemy's hybrid ORM/Query Builder approach.

While I like SQLAlchemy a lot, it has to be said that it leaks like a sieve.

Personally I think the problem is not that ORMs are leaky abstractions, it's that they often pretend not to be. SQLAlchemy just leaks unapologetically, if you struggle with ORM you can drop right down to using an DSL to construct SQL or just write SQL directly without feeling like you have to fight the ORM and mess with undocumented internals you shouldn't be touching.

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

#77
post #52
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.

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?

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

#78
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,…

As usual for Babel, there’s a plugin for that: https://github.com/leonardfactory/babel-plugin-transform-typ...

Yeah, but then you still have the same problem of ecosystem divergence. (In addition to the fact that I don't like using unstandardised features in the first place...)

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

#79
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,…

GrahpQL might be an answer.Though an incomplete answer at this point due to a mismatch between plain GraphQL and SQL; And the real issue is how to define and where to place a single source of truth for the schema an operations. So far we saw approaches where: - GraphQL schema is generated from SQL tables. Makes total sense for a project or a company that looks to capitalize on customers with existing databases (e.g.,…

The system that I’ve most enjoyed using recently has been hasura. It’s basically a plug and play graphql api that sits on top of a Postgres db. I love it. You can call your database directly from your clients, with row level permissions, and real time subscriptions. It’s just great.

hasura.io

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

#80
post #74
post #68

Earlier quoted context omitted.

I just don't get why people write queries like that in a convoluted way which is hard to decipher and possibly optimize with so many noises whose knowledge becomes useless on the next language/framework of choice than a straight forward SQL whose knowledge can live for decades.

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 SQL generated is convoluted but the way you need to write so many characters that doesn't hold a meaning is convoluted.

Post reply on HN