[ $davids.sh ] — david shekunts blog

😍 We've found a great alternative to TypeORM, Prisma, and Knex 😍

# [ $davids.sh ] · message #174

😍 We've found a great alternative to TypeORM, Prisma, and Knex 😍

It's like, 2023, and Node JS is one of the most hyped and fastest-growing stacks, but damn, there's still no clear answer to: "What good ORM / Query Builder should I choose?"

Until recently, I would have said: "They're all crap, go with Go (just kidding)"

TypeORM is buggy, unpredictable, unoptimized, and inconvenient (creating a class and then assigning values to parameters through ... what's the point of using TypeScript then?)

Prisma is not bad, but its syntax is so far from SQL that I'd call it "PrismaQL", and it's also unpredictable. The Rust binding required to run and interpret "PrismaQL" in SQL also consumes resources and is not available in some environments (e.g., serverless), and its own schema is limiting, making it hard to use any special PostgreSQL features.

Knex is more or less okay (I used it myself), but for some reason, there are almost no answers on StackOverflow, and most importantly, it has very poor TypeScript support (when .leftJoin returns T[] instead of T[] | null, that's a red flag for me).

After a long search and many doubts, the answer has finally been found!!!

**🎉 **Kysely **🎉

**It's a truly amazing Query Builder:

– Its typing is incredibly strong: .with, subquery, json_agg, parametric condition, CASE WHEN – all of this and much more is automatically and correctly typed.

– Its syntax is very intuitive and similar to SQL (the syntax for expressions and predicates is the best I've seen).

– It only needs type introspection from the database to start working (we use kysely-codegen), so it's very easy to integrate into any existing project (we're using it in new features and refactoring old ones, while legacy code still uses TypeORM / Knex).

– It's super easy to extend column introspection with custom types (e.g., branded types).

– You can fully customize the connection pool (we simply reuse the pool from TypeORM itself for integration into our project).

In short, if you want a cool Query Builder, I can now 100% recommend Kysely.

P.S.

I've been sick for the past couple of months, but I'm finally recovering, so I'll start writing more posts gradually. We've recently launched a large High Load project and are gradually transferring the load from our legacy system.

So, wait for some powerful content 💪

#nodejs #ts #orm #postgresql #top #hot

  • @ Ivan Manylov · # 522

    And how do you like Drizzle?

  • @ [ $davids.sh ] · # 523

    I even thought about writing about it: it's the second technology we would try if it weren't for kysely.

    A few things are confusing:

    – Drizzle is further from SQL than kysely: with Drizzle, you can use "with: { ... }" to get relations, which doesn't exist in SQL, meaning it will be interpreted in its own way, while kysely only uses SQL capabilities (like join or json_agg), and they are very well described. – For kysely, it's enough to have the typing (type, interface) of the database tables, which is super easy to do even with your own introspection tools (we had our own script, then we switched to the official one, but we'll go back to our own soon), and it's also very easy to extend (import into a neighboring file, customize types, use custom types). With drizzle, you'll have to use their introspection (it broke on our databases due to incompleteness with some types) + I don't understand at all how you can extend its introspection yet. – IMHO, kysely has more advanced documentation.

    But considering that kysely worked, I have no reason or advantage to even look at drizzle, because kysely covers a much larger part of my needs, the main one being to have maximum type safety and flexibility in writing non-standard SQL queries (I'll show an example in the next post).