Today, I was discussing with a friend which PostgreSQL client (ORM) he should use. Choosing the best option is a challenging task, but there’s a spicy take I always bring up in this conversation: avoid using Prisma as your ORM.
Table of Contents
Introduction
Why Not to Use Prisma?
Why Is This a Problem?
Deep Diving into the Problem
Consequences
When Should I Stop Using ORMs?
Conclusion
Why Not to Use Prisma?
If you’re unfamiliar, Prisma is a well-known TypeScript ORM for PostgreSQL and MongoDB. It was the first ORM I learned to use, and this decision led to some difficulties later on.
Prisma’s primary issue is that its entity creation and database modeling only work with their own language.
Why Is This a Problem?
First, let’s compare a Prisma entity with a TypeORM entity to understand what makes Prisma different from other ORMs on the market.
The code above represents a TypeORM implementation of a user entity.
As you can see, we’re using TypeScript to validate all the fields based on their types or relationship references. In the code above, I used the library class-validator to apply the validation decorators.
The code above represents the same entity, but rewritten entirely using Prisma’s own language.
Deep Diving into the Problem
What’s the problem here?
At first glance, it might seem trivial, but it actually makes a lot of sense: with Prisma, you’re forced to create all your logic using their programming language (or markdown language, I’m not sure what it’s called).
This specifically prohibits you from using external libraries or JavaScript code to build more reliable logic in your entities.
Consequences
Since you can’t use JavaScript in your code, you should expect to waste a lot of time trying to figure out how Prisma’s scaffolding language works and how to create schemas using it.
There’s also one very important detail: you can’t use any external library or helper.
Imagine a situation where you need to customize the way your primary keys are generated. With TypeORM, you can simply use this approach:
However, to achieve the same result using Prisma, you will need to do something like this:
When Should I Stop Using ORMs?
There is an interesting discussion where developers argue that using ORMs is a mistake and they need to stop it as soon as possible.
I really disagree, but with some conditions.
I agree with freeing yourself from ORMs when they function like Prisma: they expect you to learn a completely new language or methods just to make it easier to write code.
“Wait, are you saying that creating an easier ORM is bad?”
No. I am saying that removing the flexibility of writing more raw-like queries to make the ORM easier can cause issues for developers, such as forgetting how to use SQL.
Conclusion
This article is clearly a matter of opinion, but I am trying to illustrate a straightforward point: you should not use ORMs that force you to be distant from SQL queries. Your ORM should help you better organize and formulate your queries, not write entire queries for you.
What do you think?
Photo by Milad Fakurian on Unsplash
