Discussion on "Node.js ORMs overview and comparison"

Roman · 2022-06-24T03:47:54.288Z

I believe that ORM is the most important tool for backend development, the tool we spend the most of our time working on a feature, the tool we scold the most, always wanting something better. Here I'm doing a review of 6 popular ORMs to compare and ...

You should add Kysely to the list. Without the benchmarks part would be fine.

Kysely is great and I was happy to use it in my last work project.

In theory, implementing "real world app" with Kysely might have some quirks (or maybe not), but implementing this app one more time is time-consuming so not gonna do that.

Though it would be interesting to see if it's much easier to use than Knex, as they are similar, but take different approaches for query builder design.

I usually don't comment on stuff, but well done on this really good article. Thanks for the sweet summary!

Roman very nice writeup!

Understood if you're tired of learning yet-another-ORM at this point :-), but if you want to check out Joist (joist-orm.io), it's an ORM we've written and would appreciate your input/thoughts on it.

To your chagrin, we'd also don't have a robust query builder yet :-) (we defer complex query use cases to Knex for now), but we do consider ActiveRecord to be a big source of inspiration (a lot of our domain objects, validation rules, and lifecycle hooks are inspired by ActiveRecord).

I think in a few cases we've surpassed ActiveRecord in ergonomics (specifically since we build on dataloader, we get N+1 avoidance basically for free; and our reactive rules & derived fields is pretty unique I think), but overall it's still a high bar to meet!

Nice in depth article. I've dabbled in Prisma for the past few months. The community is getting pretty big and it is definitely handy at a startup level. There are still a few things they still need to work on like Optimistic Concurrency Control feature updateMany still has a bug (hopefully will be fixed soon), no nested createMany (doesn't make a big deal breaker). With PostgreSQL they released GIN, GiST, SP-GiST, and BRIN indexes support on 3.14.0 my interest is in BRIN for time scheduling. I was trying to avoid decorators so that's why MikoORM was out otherwise it would have been my second choice.

Curious to know what review for code first graphql SDL like Nexus/Nexus-Prisma vs Pothos you would prefer next? IMO Pothos has some really good documentation and the code is readable but the dot notation with Nexus/Nexus-Prisma is smooth (once you can fully master it i think...)

Writing in depth article is so time consuming, because need to take a library, to read it's docs and learn how to use it, then to write bunch of code to see in action. Most of the time spent on fighting with bugs, limitations, digging issues. And it was very pleasant to get a lot of positive comments for my first large post (on reddit many people said it's good written, bookmarked).

I really like the topic of ORMs because that is a tool I work with primarily for many years, and I'm developing own, so I wanted to see what the market has and to get inspiration.

GraphQL solutions overview is a bright idea for an article, but I don't work with GraphQL usually, so not motivated for this.

I enjoyed working with "fastify mercurius" for GraphQL, but it's schema first. After changing schema it generates all the types, and only need to implement resolvers and data loaders.

Wow-what a thorough article good one!

Very informative Roman thanks!

Hey Roman! I took a few looks at Orchid. I like the docs! In terms of feedback, I think my biggest take away is what you also highlight in your docs: personally I wouldn't really call Orchid an ORM, and instead would call it a query builder, ala Knex and Kysely. Granted, "query builder" doesn't really roll off the tongue like "ORM" :-). "Query DSL"? Hm, not sure. Terminology pedanticism aside :-), congrats on shipping!

Stephen Haberman thank you for checking it out!

I understand your point, so I added an explanation on the very first page of the docs that is not a "traditional" ORM. But it is an ORM like Prisma.

None of the query builders is helping with relations, literally none of them, so if I call it a query builder it's like ignoring the most fun part of it: working with relations. Here is a code example in benchmarks section.

Calling it a DSL or a database SDK would tell nothing to potential users. Everyone knows Prisma, and I guess if they can call it ORM, then mine can be called too.

Anyway, there are no strict clear bounds of what ORM is. Different people have different expectations.

So for me, query builder is abstracting only tables, while ORM is also abstracting relations. And how exactly it is implemented - instantiating class or not - is just an implementation detail.

Roman hey!

But it is an ORM like Prisma.

Ah yeah, that's a good point; I suppose I have the same qualm with Prisma as well :-D

query builders is helping with relations

Ah interesting, yeah that is a good point. Thanks for linking to the nested load example. That is a nice way to handle the boilerplate of joins. Looks nice!

With Joist, I've shied away from doing any query building that is not "return me exactly this entity", with the rationale that we'd probably be best off using custom SQL/knex queries for that anyway, but yeah I can see how those "custom"/"not-an-entity" result queries are much nicer in Orchid than doing joins in a query builder. Nice job!

Bookmarking for later. :-)

Roman it's definitely no easy task writing up multiple ORMs and takes enormous amount of time. I know most people go the REST route but GraphQL it definitely nice to scale. I know for me working in graphql in a work project makes a lot of sense once you understand it because it applicable later on and no major changes are needed. Looking forward to your next article keep it up.

GraphQL is awesome, it's a better approach in almost every way.

The flow: define a GraphQL schema, if it's schema first generate TS types with one command, if it's code first generate schema, implement resolvers and data-loaders and let the types to guide you. I work with React usually, so next step is to generate types and ready to use hooks for the frontend. And you have API docs and playground for free. I love this flow, it saves a lot of time, less code to support, API is more unified.

There is a one question I'm not sure how to solve in GraphQL, what if evil client will load too much of nested resources making server to feel sick, but there must be a way to solve it.

For some reason, GraphQL is still not too popular, perhaps people think it's more complex, or they know some flaws, so in my experience where I worked it was always a REST API, so I'm not very familiar with GQL and only learned it by using on a pet project. If by any chance you'd like to write an article about Nexus vs Pothos, and for me vs Mercurius, there is also typegraphql, apollo server, I'd love to read it!

Discussion

Node.js ORMs overview and comparison

Responses(7)

Recent in Forum

Search Hashnode

Node.js ORMs overview and comparison

Responses(7)

Recent in Forum