Live data from Hacker News

Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

github.com

71–80 of 87 posts

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#71

Earlier quoted context omitted.

Super cool, looks great. Interesting to see you built it with Typescript. I was wondering-- and I know this is a long story, but I am curious: How does one go about building a PostgreSQL driver for NodeJS in Typescript? How do you design and begin that sort of thing? What sort of knowledge resources did you rely on (i.e. documentation, other references)? I googled 'database driver' to get a definition: "A database dr…

Thanks a lot. I did not built it with Typescript, just plain js - I don't use Typescript at all(not my cup of tee), but a kind soul (thanks @minigugus) contributed the typings ;) I actually began it out of curiosity and because I was missing features in the current options. I had been using a wrapper around pg-promise to give me the API i wanted for quite a while, and one day when going through the PostgreSQL documen…

No post body was provided.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#72

Earlier quoted context omitted.

I can only assume that I've finally found a soulmate that just don't like writing TS code. Like, in my full-time job I'm using 100% TypeScript, but I don't really ENJOY writing in it - that's why in my all side-projects I use good old JavaScript. I think it's just a personal syntax preference. But I don't want to answer this for the OP, just added my 2cents, maybe he has similar feeling about it :)

Haha.. There's plenty of us out there, it's probably just that we'd rather do actual stuff than talk about doing it. A bit like Typescript - it doesn't really do anything, it just talks about it. Joking aside, I generally don't want to get into the debate, because I believe people work differently, and there should be room for doing both things. It's just a bit sad that Typescript is being pushed so hard as if it's t…

No post body was provided.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#73

Earlier quoted context omitted.

I can only assume that I've finally found a soulmate that just don't like writing TS code. Like, in my full-time job I'm using 100% TypeScript, but I don't really ENJOY writing in it - that's why in my all side-projects I use good old JavaScript. I think it's just a personal syntax preference. But I don't want to answer this for the OP, just added my 2cents, maybe he has similar feeling about it :)

Haha.. There's plenty of us out there, it's probably just that we'd rather do actual stuff than talk about doing it. A bit like Typescript - it doesn't really do anything, it just talks about it. Joking aside, I generally don't want to get into the debate, because I believe people work differently, and there should be room for doing both things. It's just a bit sad that Typescript is being pushed so hard as if it's t…

> It's just a bit sad that Typescript is being pushed so hard as if it's the only right way.

It's being evangelised as if it has zero downsides, it introduces overhead to what can already be a brittle dependency/build chain - providing questionable levels of actual type safety. This is coming from someone who generally prefers typed languages too, Typescript to me is the exception to that rule.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#74

Earlier quoted context omitted.

> Any plans for Knex support? That question doesn't really make sense. I'm not familiar with this library, but the developer interface is very similar to slonik. The whole point of this is that SQL tagged template literals replace the need for a query builder like Knex. Here is a good blog post from the author of slonik explaining: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...

I'm broadly a fan of just writing SQL, but Knex does have one important advantage: it automatically declares the return types from a query based on my DB structure. If I write SQL by hand, I have to annotate the query with the return types, and those annotations can get out of sync with the query.

Slonik has a typegen package that works great, https://www.npmjs.com/package/@slonik/typegen

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#75

Earlier quoted context omitted.

Ok, I'd have to double check to see if the Unlicense is ok for work projects, but this is a great contribution to the node ecosystem.

I actually replaced WTFPL with Unlicense since someone at google couldn't use it, so I would think it's ok?

Any reason you can't use MIT.

For hobbyist projects Unlicense is great, but it may create issues with bigger companies. I think the main sticking point, is public domain that doesn't really exist in countries like Germany, so the unlicensed is unclear. Companies don't like unclear things.

Facebook uses MIT, and their tools like React and Jest are cornerstones of the NodeJS ecosystem.

https://github.com/facebook/react/blob/main/LICENSE

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#77

I spent some time today trying to replace pg but I ran into an issue. When using an rds proxy with iam authentication, it seems to repeatedly retry authentication and eventually my lambda functions time out. If I switch to using regular credentials it works fine. Using the exact same options with pg+iam authentication also works fine which leads me to believe it's an issue with this project. I'll open an issue on Git…

Be very interesting to know if it is the rds proxy that is causing the problem. It is one things that annoys me about rds and aws services.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#78
post #51

Earlier quoted context omitted.

I responded to the OP, but I'll add here too for the conversation. Where are these projects that are implementing network protocols, where the nodejs versions are faster than the native ones? As I noted in my other comment, in -any- of those implementations, you're still going to be required to traverse from libc somewhere to nodejs (even if it's just to read the network data out of the socket and send it to v8). The…

> The performance gains would have to either come from a faster (JIT'd) protocol parser, or from eliminating additional FFI calls (that it isn't obvious why they'd exist). or, as I noted above, and will try to simplify here: let's suppose you have a buffer which contains 5 key/value pairs, and you want to convert that into an array of 5 javascript objects in v8. 1. obtain a pointer to the isolate 2. create an array o…

Hey Jerry!

I'll respond here so we don't have split threads :). I'm also quite familiar with at least the older versions of the node internals (I too maintained a popular db binding for a number of years) and I'm very confused by the way you're positioning the operation of the v8 vm in these 2 scenarios. Sure, the c++ is going to require you to do some sanitizing as you force your data into v8, but as we noted that's inevitable no matter how you slice it. After that though, even once in javascript land, you're still crossing these barriers constantly to allocate data and objects and memory, etc. You don't just end at 'parse in javascript', the virtual machine is going nuts calling into this same c++ codebase. Now maybe in some cases the v8 internals offer some advantages the generic c++ api can't access, but this argument isn't convincing of their existence so far.

My memories of the redis client is different than yours so I'd be quite interested to see those conversations / benchmarks. From what I recall those early advantages in the js redis client were similar to the ones we're seeing here, ie: better pipelining of commands.

As a simple thought experiment, in the scenario you're describing we should see a javascript implementation of a JSON parser to beat the pants off the v8 engine implementation, but this doesn't seem to the case.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#79
post #62

Earlier quoted context omitted.

Hey. Love this lib. I am curious why you decided against using TS here? You mentioned it's not your cup of tea.

Some people really love the simplicity that comes from zero compilation. I like that too, so I always start with just JS, but then two files in realize I really want my typings. Now I use esbuild instead of tsc, and I have the best of both worlds.

> Now I use esbuild instead of tsc, and I have the best of both worlds.

I'm interested in this. I know esbuild can compile TypeScript to JS, but that it doesn't serve as an actual typechecker. Without tsc as a dev dependency, do you just rely on your IDE's intellisense to tell you when there's a type error?

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#80

Earlier quoted context omitted.

Hey. Love this lib. I am curious why you decided against using TS here? You mentioned it's not your cup of tea.

I can only assume that I've finally found a soulmate that just don't like writing TS code. Like, in my full-time job I'm using 100% TypeScript, but I don't really ENJOY writing in it - that's why in my all side-projects I use good old JavaScript. I think it's just a personal syntax preference. But I don't want to answer this for the OP, just added my 2cents, maybe he has similar feeling about it :)

Yep! I'm the same way -- it comes from a love of simplicity and an affair I had with Lua, which I find marvelously simple and inspirational.
Post reply on HN