Context and Problem Statement¶

We want to eliminate the need for writing boilerplate code for db crud operations, at the same time greatly reducing maintenance efforts and time for implementation.

For this purpose we want to utilize a type safe orm library.

Decision Drivers ¶

Decision drivers for choosing the orm library:

• Types generation
• Type-safe operations
• Declarative
• Abstracted
• Db Migration management
• Supported databases
• Well-maintained
• Widely used

Considered Options¶

• prisma
• typeorm
• sequelize

Decision Outcome¶

Chosen option: "prisma" because it:

• has great type generation and type safety (both compile and runtime during record creation/retrieval)
• has great abstraction over the chosen database, really declarative, no sql visible
• is third most used of the options considered
• supports no sql database as well (MongoDB)
• great db migrations control
• is database agnostic

Positive Consequences ¶

• Hugely improved time to implementation, less maintenance

Negative Consequences ¶

• The most efficient queries are not guaranteed, though for our current outlook we are not doing anything extreme that might require such optimizations
• The need for more control might arise, we would be limited by the capabilities of the library

Pros and Cons of the Options ¶

sequelize¶

• Good, because its most widely used and maintained
• Good, because it is declarative and offers good abstraction
• Good, because it offers great db migrations control
• Good, because it has extensive cli
• Bad, weak type-safety out of the box
• Bad, because the types support is a work in progress, and yet another lib needs to be used to achieve it
• Bad, because there is no runtime type check support
• Bad, because it does not support no sql db

typeorm¶

• Good, because it supports no-sql database (MongoDB)
• Good, because it has strong type-safety
• Good, because its widely used and maintained
• Bad, because migrations have to be added manually and seem complicated to set up
• Bad, because migrations have to be written in specific sql dialect

prisma¶

• Good, because it offers generation of migration scripts by detecting the diff
• Good, because it is completely agnostic of the underlying database, easy to switch db
• Good, because it offers great type safety both compile and runtime
• Good, because it offers great db migrations control
• Good, because it is widely used and maintained
• Good, because it also supports a NoSql DB
• Good, because it requires very few lines of code
• Good, because it offers a UI play with data in the database, useful also for development
• Bad, because not all things are clear under the hood (env vars management)
• Bad, because it uses custom schema syntax, though it allows for easy db change

Links ¶

• NPM Trends