Comment by Nathan Froese on "Node.js ORMs overview and comparison"

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.

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!

Search Hashnode