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.

▲ jherdman 3 days ago | parent | next [-]

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

▲

internetter 3 days ago | parent | next [-]

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

▲

jherdman 3 days ago | parent [-]

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.

	▲	internetter 2 days ago \| parent [-]
		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

▲

pier25 3 days ago | parent | prev [-]

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.

▲

bytehowl 3 days ago | parent [-]

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

	▲	pier25 2 days ago \| parent [-]
		Thanks I wasn't aware of this

▲ rozenmd 3 days ago | parent | prev | next [-]

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

	▲	verdverm 3 days ago \| parent [-]
		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

▲ jgehrcke 3 days ago | parent | prev | next [-]

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"

▲ breakfastduck 3 days ago | parent | prev | next [-]

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

▲ tracker1 3 days ago | parent | next [-]

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.

▲

breakfastduck 3 days ago | parent | next [-]

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.

	▲	tracker1 3 days ago \| parent [-]
		I mostly use grate.

▲

pier25 3 days ago | parent | prev [-]

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.

▲

tracker1 3 days ago | parent | next [-]

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.

▲

pier25 3 days ago | parent [-]

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.

▲

tracker1 3 days ago | parent [-]

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.

▲

mrsmrtss 3 days ago | parent [-]

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.

▲

tracker1 3 days ago | parent [-]

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.

	▲	pier25 3 days ago \| parent [-]
		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.

▲

pjmlp 2 days ago | parent | prev [-]

Only if using the wrong kind of editor.

▲ carderne 3 days ago | parent | prev [-]

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

▲ tracker1 3 days ago | parent | prev | next [-]

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.

▲ adzm 3 days ago | parent | prev [-]

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.