Hacker News Reader

Comment by pier25 | Hacker News Reader

I would have picked Hono and Drizzle. In part because of the great TS support but also Hono is much faster than Express and supports Zod for validation out of the box. This stack would also allow to use any other runtime (Deno, Bun, or Cloudflare Workers).

Given they used TS and performance was a concern I would also question the decision to use Node. Deno or Bun have great TS support and better performance.

View on HN

Have you tried Elysia (https://elysiajs.com/)? Admittedly I'm not using it at scale, but it's quite pleasant.

I've written 10s of thousands of lines of Elysia+Kysely and its a match made in heaven

I’m curious about your choice of Kysely. I’ve really only used Drizzle. It’s fine but it has some very rough edges around Bun and SQLite.

I'd rather use SQL than an ORM. Kysely is basically a wrapper for the SQL query syntax inside typescript which has the benefit of composability and incredibly rich typescript support

I checked it out and it looks good on paper but it only runs on Bun.

Don't get me wrong, I use Bun and I'm happy with it, but it's still young. With Hono/Drizzle/Zod I can always switch back to Node or Deno if necessary.

ElysiaJS's blog claims that support for other runtimes was added in 1.2: https://elysiajs.com/blog/elysia-12.html#adapter

Thanks I wasn't aware of this

I recently moved a classic HTTP API server from Express to Hono (through the Hono node-server package), absolutely seamless migration.

I wouldn't call it seamless, having also done this recently. (Handler func signature is different) But it is relatively straight forward without major changes to the code needed

I'm sure you know what you're taking about -- yet, your response reminds me of https://youtu.be/aWfYxg-Ypm4

"drizzle works on the edge"

I've had a really pleasant experience with Drizzle as an ORM. It feels straightforward compared to some of the incredibly bloated alternatives.

I'm more a fan of just a sql template string handler... in C#/.Net I rely on Dapper... for node, I like being able to do things like...

    const results = await query`
      SELECT...
      FROM...
      WHERE x = ${varname}
    `;

Note: This is not sql injection, the query is a string template handler that creates a parameterized query and returns the results asynchronously. There's adapters for most DBs, or it's easy enough to write one in a couple dozen lines of code or less.

Sure, looks good. I often do templating.

However drizzle makes it very very straightfoward to handle DB migration / versioning, so I like it a lot for that.

I mostly use grate.

With something like EF Core in .NET or Drizzle in TS you get a lot of help from your editor that you wouldn't get when writing SQL.

In TS, I can still create a type for my result... const results : Promise<Foo[]> = ...

I'm not sure what additional help you're getting. I'm just not a fan of ORMs as they tend to have hard edges in practice.

ORMs not only help with the result of the query but but also when writing queries. When I wrote SQL I was constantly checking table names, columns, and enums. With a good ORM like EF Core not only you get autocomplete, type checking, etc but dealing with relationships is much less tedious than with SQL. You can read or insert deeply nested entities very easily.

Obviously ORMs and query builders won't solve 100% of your queries but they will solve probably +90% with much better DX.

For years I used to be in the SQL-only camp but my productivity has increased substantially since I tried EF for C# and Drizzle for TS.

VS Code plugs into my DB just fine for writing SQL queries...

With an ORM, you can also over-query deeply nested related entities very easy... worse, you can then shove a 100mb+ json payload to the web client to use a fraction of.

That's just nonsense. It's trivial to make efficient projected queries with ORMs like EF. Nothing stops you doing stupid things with plain SQL either.

No, but it does put you closer to the actual database and makes you think about what you're actually writing. You also aren't adding unnecessary latency and overhead to every query.

Better DX is not unnecessary.

Also the overhead of good ORMs is pretty minimal and won't make a difference in the vast majority of cases. If you find a bottleneck you can always use SQL.

Only if using the wrong kind of editor.

Bit of a plug but I just started working on a drizzle-esque ORM[1] for Python a few days ago and it seems somewhat appropriate for this thread. Curious whether anyone thinks this is a worthwhile effort and/or a good starting point syntax-wise.

https://github.com/carderne/embar

Made pretty much the same comment Hono + Zod + Swagger is pretty nice all around. Not to mention the portability for different runtime environments. I also enjoy Deno a lot, it's become my main shell scripting tool.

I think it makes sense to start with node.js... it's the standard and widely supported. Eventually it should not be too difficult to switch to bun or deno if the need arises.

Reply on news.ycombinator.com