The demo gif is fabulous.
Thanks a lot!
PostgresJs: PostgreSQL client for Node.js and Deno
71–80 of 148 posts
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#72Shout out to https://www.npmjs.com/package/sql-template-strings , which does a similar template string SQL escaping standalone.
Had to check if I wrote that lib. I wrote pretty much the same thing, not sure if I published it standalone...
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#73For people who would like a more safe and structured approach (but almost as powerful and with the option to resort to SQL strings if needed) I highly recommend checking out Prisma https://www.prisma.io/
Prisma doesn't do JOINs [0], it just SELECTs everything and joins them in its own engine. It should not be taken seriously. [0]: https://github.com/prisma/prisma/discussions/12715
I thought the webdev startup shtick is to build fast and optimize speed where your bottlenecks are later. If Prisma helps you write 90% of your queries faster, you can still just drop down to SQL for efficient joins the rest of the times.
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#74Earlier quoted context omitted.
Are there no times this would be preferable? Just curious. It seems like the DX Prisma provides could potentially outweigh the need for joins, especially if you don’t have a ton of referentiality. I’ve been a very happy Prisma user for a couple years now and take it very seriously fwiw.
Take this with the bias of a grumpy SRE/DBRE. The only reason to not support JOINs is because of the added complexity. However, since ORMs are supposed to (among other things) reduce the complexity for the user, not the DB, this seems like a poor decision. There are other ORMs for the JS world. I can't imagine that they're all so much worse than Prisma as to render them non-choices. > outweigh the need for joins At t…
I think the access pattern that Prisma uses (for a given records from X, give me it's relations to Y, then give me Y's nested relations to Z in a unified data model), using multiple queries may the the _best_ way (not necessarily the most efficient) to do it to produce the resulting object model.
If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every table to have all the relevant data) and you'd have to manually reduce the rows into the data structure you'd want; either in the db or in biz logic. You may be able to swing it somehow using Postgres's json functions but then it gets _super_ messy.
Prisma avoids that by just requesting the relevant level(s) of data with more discrete queries, which yes, result in _more_ queries but the bottleneck is really the latency between the Rust Prisma engine and the DB. Again, we're sacrificing some speed for DX, which imo, has made things much cleaner and easier to maintain.
You can also use cursors for pagination, which is definitely in their docs.
I see your points but unless there's some extreme network latency between your app(s) and the db (which can be minimized by efficiently colocating stuff) 300-500ms seems extreme. I would be curious if you logged out Prisma's queries and ran them independently of the client, whether you see the same latency.
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#75For people who would like a more safe and structured approach (but almost as powerful and with the option to resort to SQL strings if needed) I highly recommend checking out Prisma https://www.prisma.io/
Prisma doesn't do JOINs [0], it just SELECTs everything and joins them in its own engine. It should not be taken seriously. [0]: https://github.com/prisma/prisma/discussions/12715
This just feels like throwing the baby out with the bath water. For one, they're slowly adding more joins to queries, and two, a lot of times there's almost no performance difference.
This has been much discussed in many GitHub issues. People get stuck on joins because it's how they've always done it. Same with now Vercel convinced everyone they need SSG and not just a cache
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#76Used pg for years then migrated to postgres.js about two years ago. I love it and have had zero issues.
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#77Earlier quoted context omitted.
What does fast actually mean specifically? The slow bit isn't the client, surely?
Sorry, but you’ve been fooled by the web and functional programmers propaganda against performance. Also, what the author seems to mean is that this is faster than specific python, js and go clients. Anyway. At the IO boundary, there’s a lot of syscalls (polls, reads, mallocs especially), and how you manage syscalls can be a major performance sticking point. Additionally, serialization and deserialization can have pe…
> The slow bit can definitely be the client.
Yes, but for 99% of "slow database" scenarios : no.
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#78Shout out to https://www.npmjs.com/package/sql-template-strings , which does a similar template string SQL escaping standalone.
Had to check if I wrote that lib. I wrote pretty much the same thing, not sure if I published it standalone...
> Had to check if I wrote that lib..
This reminds me of a friend of mine.. He got struggled with a programming-related task. When he gave up, he turned to StackOverflow, where he found the exact answer there, ready to be copy/paste. Ironically, it turns out that he was the one who answered it a few years back :)
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#79Earlier quoted context omitted.
Take this with the bias of a grumpy SRE/DBRE. The only reason to not support JOINs is because of the added complexity. However, since ORMs are supposed to (among other things) reduce the complexity for the user, not the DB, this seems like a poor decision. There are other ORMs for the JS world. I can't imagine that they're all so much worse than Prisma as to render them non-choices. > outweigh the need for joins At t…
I think the access pattern that Prisma uses (for a given records from X, give me it's relations to Y, then give me Y's nested relations to Z in a unified data model), using multiple queries may the the _best_ way (not necessarily the most efficient) to do it to produce the resulting object model. If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every tab…
> If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every table to have all the relevant data)
ARRAY_AGG for Postgres or GROUP_CONCAT for MySQL does what you’re asking without duplicating rows.
Re: JSON, don’t. RDBMS was not designed to store JSON; by definition you can’t even get 1st Normal Form once its involved.
IMO, claims of DX regarding SQL just mean “I don’t want to learn SQL.” It’s not a difficult language, and the ROI is huge.
Re: PostgresJs: PostgreSQL client for Node.js and Deno
#80Earlier quoted context omitted.
Prisma doesn't do JOINs [0], it just SELECTs everything and joins them in its own engine. It should not be taken seriously. [0]: https://github.com/prisma/prisma/discussions/12715
This just feels like throwing the baby out with the bath water. For one, they're slowly adding more joins to queries, and two, a lot of times there's almost no performance difference. This has been much discussed in many GitHub issues. People get stuck on joins because it's how they've always done it. Same with now Vercel convinced everyone they need SSG and not just a cache
People have always done it that way because it’s to date the most performant and efficient way to do so. RDBMS have enormous amounts of logic devoted to turning your query into the most efficient possible access pattern.
If what you want is NoSQL, then use NoSQL.