Hacker News Reader

Comment by ponyous | Hacker News Reader

I'm just about to start working on DB layer for our app with TypeScript. Any other alternatives to prisma you guys prefer and why?

View on HN

(haven't tried Prisma)

TypeORM -> classic ORM, the "default" choice in node, but not very mature compared to what exists in Java or things like Django ORM. In my experience it's not an amazing lib, transaction management is a bit painful, I've seen a couple bugs happen.

Knex -> it works but not sure why you'd use that rather than TypeORM

MikroORM -> not a lot of experience, one of my colleagues really likes it, read the principles behind it and see if that talks to you as it's a bit opinionated

Slonik -> Never used it but probably what I'd set up on a new project. Like many people I think that query builders are BS and I'd rather use SQL: Slonik makes that very easy while giving you the usual getOne/getMany utilities

I'd like to try Prisma though, I've heard good things

TypeORM is poorly maintained (the lead author had a breakdown and appears to be inactive, and failed to delegate ownership to others), and is riddled with bad abstractions, poor design choices and an enormous pile of game-breaking bugs that make the TypeScript types unsafe and it’s usage clunky and dangerous. I would absolutely use knex, which works, over TypeORM, which routinely doesn’t.

Interesting -- I actually haven't had as many problems as you have with TypeORM -- it's just mostly worked. Then again, maybe I'm a rare case, because I basically ignore the ORM side and use a little repository pattern, the query builder, and write my own migrations in SQL (as in all the migrations are `await queryRunner.query(...);`).

It's been excellent for me -- I ignore the bad abstractions, have a good underlying database (postgres), and drop down to parametrized raw SQL whenever I need to, it's held up extraordinarily well I think.

Could you expand on some specific issues/frustrations? Just curious about the side I'm clearly not seeing.

This is the one upside I’ve had of using TypeORM: I find its query abstractions so unreliable and surprising that it’s forced me to get better at SQL!

And once you're good at SQL, it will never let you down. Query builders + reasonably abstracted libraries for the repetitive things (the repository pattern in TypeORM gets me just about all the CRUD I need), and query building/raw queries for the rest.

The things that the DB can do (I'm thinking about postgres) are amazing, and you just aren't going to get a chance to use a lot of it really from a lowest common denominator ORM. Yeah, you probably don't need it -- but then again why not just use a tool like Postgrest from the start?

Lmao. This happened to me too no joke

Yeah my issues are from trying to actually use the advertised functionality of the library. Issues include migrations being generated incorrectly, lots of footguns (for example it’s extraordinarily easy to instead of deleting a particular row, to delete your whole table, and their typescript typings are too general to make it clear what you’re doing), the pattern of making instances of relations that lack all the fields that are required in the DB leads to the type system becoming unreliable (fields that should always be present in the DB, may not be in JS), transformer functionality has a ton of bugs as well. I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs.

The downside for me about dropping into raw SQL is that it makes much of the usefulness of an ORM in being able to refactor your schema and stuff disappear, because the type system and instrumentation can’t auto-refactor a raw SQL string. But I agree that I’d take that over relying on TypeORMs bugginess.

Thanks for sharing this insight, it makes a lot more sense to me now, saving this (in my brain) for the counter argument to TypeORM.

> I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs.

So just a side note on this, I judge repositories based on teh ratio of closed to unresolved (and whether they have a bot that auto-closes issues). 200+ unmerged PRs is bad -- that maintainer needs help. I've interacted with the main maintainer before a long time ago and I had a good impression, but they probably weren't ready for how big their project got (how can anyone be) and they clearly didn't charge enough to make it a joy to work on their project. Money isn't the main motivator for everyone, but it would enable hiring people, or taking vacations as appropriate, etc.

Yeah, a lot of people have been saying that on the pinned mega-issue re the future of TypeORM - but the maintainer doesn't seem to have done much to fundraise nor pass on leadership to others. This seems to be moving slightly - some contributions are slowly trickling in. But at this point I think alternatives like Prisma will just eat the pie.

This matches my team’s experience with TypeORM. It’s full of bad surprises. We use it exclusively with a read-only account because we don’t trust it to change our data under any circumstance. Our current plan is to move to MikroORM, Prisma 2, or just give up on Node completely.

Just as a side-note, we have migration guide from Prisma to TypeORM in our docs: https://www.prisma.io/docs/guides/migrate-to-prisma/migrate-...

I think you meant from TypeORM to Prisma

My preferred DB layer is Objection.js[0] which is simply an ORM-layer on top of knex[1], with official TypeScript support.

[0] https://vincit.github.io/objection.js/

[1] https://knexjs.org/

Hey, Nikolas from Prisma here.

There are quite a few other ORMs for working with DBs in TypeScript (none of them providing the same type-safety guarantees that Prisma does though [1]).

In fact, we laid them out on a docs page [2] in case you want to learn which tool might be appropriate for your use case.

[1] https://www.prisma.io/docs/concepts/more/comparisons/prisma-...

[2] https://www.prisma.io/docs/concepts/overview/should-you-use-...

Thanks, that's really useful.

I suggest to not add a layer. Stay close of the SQL request, you can simply have a function that will fulfill an access pattern. No need for ORM.

Yeah, I have no problem with minimum ORM (prepared statements type of thing) - That's why I am asking the question, Prisma seems a bit too much. Usually I just use simple ORM helpers (get by primary key for example) and anything complex is raw sql.

What I am looking for is ideally something that helps with type saftey and seeds/migrations/schema creation.

Try Knex!

https://github.com/gajus/slonik

I'm wondering at the moment whether Knex (solid query builder and migration) and Objection.js would not do this trick. That combo seems to give me json validation which is nice and seemingly both a way to handle entities and graphs in an efficient way.

https://jawj.github.io/zapatos/ (no built-in migration support, though)

I have been using Flyway with Node.js. Works all right and you write everything (migrations, schema, seeds) in SQL. It does make working with SQL quite straightforward and non-magical.

The thing is of course that with very complex queries you'll end up making quite intricate string building stuff which may not be very pretty. I myself am curious to find out if Prisma can make that part go away.

There are many discussions on reddit about Prisma vs TypeORM in particular. For example here: https://www.reddit.com/r/node/comments/l3xu6w/is_prisma_a_vi...

There is also a good discussion going on here: https://www.reddit.com/r/node/comments/l00fit/what_do_you_th...

MikroORM. I think it's the best ORM for TypeScript.

If you want an orm that encourages you to use sql instead of abstracting it, you can look at my library: https://github.com/Seb-C/kiss-orm

I love knex and simply write small functions and roughly keep one file/folder per table. So: user.create(db, { name: .. })

TypeORM or MikroORM, any of those should be fine

Reply on news.ycombinator.com