Thanks for sharing your thoughts about Prisma.
> Plus i have a hard time seeing the benefit of Prisma
Prisma is supposed to improve your productivity and confidence when working with a database. It does so with a strong focus on type safety.
Most ORMs and query builders in the Node.js/TypeScript ecosystem do not provide the level of type safety that Prisma does.
For example in a blog with users and posts (1:n) querying a user and related posts looks as follows:
const user = await prisma.user.findOne({
where: {
id: 1
},
include: {
posts: true
}
})
console.log(user.posts)
The
user object will have the correct TypeScript type, including the posts object. If you remove the include object from the
findOne call and avoid fetching related posts, the user's type will change. This approach to type safety helps in catching many problems at build time.
It's possible because of the Prisma schema, which is the single source of truth for both the database schema and the generated TypeScript client.
You don't have the burden of mapping between the database schema and the types in their application. Besides that, it's a declarative and concise description for the database schema and is database agnostic.
The type safety features come at "zero-cost" because you don't have to write all the TypeScript types and mappings to the database. Prisma generates the TypeScript client from your Prisma schema.
> You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise
The Prisma schema is actually fundamentally different to JS or TS because it's declarative rather than imperative.