[2color]

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.

[exevp]

I understand where Prisma is coming from with the custom DSL: they want to guarantee type safety and therefore need to know exactly the structure of the types the result set is supposed to be mapped to.

In most other languages you'd shout "reflection" but unfortunately, there is no such thing in TS. Hence the custom DSL so you know, while parsing, what the structure of the type is.

I'm just asking myself: why invent the custom DSL for that? You could just use babel to parse TS types. Sure babel is quite the dependency but in a node environment, that wouldn't be a bigger concern to me then inventing a custom DSL instead.

You could even use TS decorators to add more metadata like sequences and (foreign) keys to the TS types.

[2color]

> I'm just asking myself: why invent the custom DSL for that?

Fair question. Besides all the type safety features I mentioned above, having the DSL (Prisma schema) allows generating database clients in more than one language, e.g. Go without the database declaration being tied to a specific programming language.

It's also the reason it's declarative in contrast with most ORMs that rely on an imperative language to define these mappings.

The second reason is that the Prisma schema is used for declarative database migrations with Prisma Migrate.

The third reason is that Prisma supports introspection of an existing database. So if you were to introduce Prisma to an existing project, you'd introspect the database which would populate the Prisma schema based on the database schema. This would then allow you to use Prisma for migrations.

Could all that be achieved without a custom DSL? Perhaps. But it'd probably tie Prisma to a specific language ecosystem and would diminish the developer experience of the features it offers.

I can understand the reluctance around a new DSL, but in reality, I haven't seen many complaints about the need to use it.

[joshmanders]

I have this same stuff in TypeORM but don't have the DSL issues that exevp mentioned..

[2color]

I think this article does a good job of comparing the two if you're familiar with TypeORM: https://medium.com/better-programming/prisma-vs-typeorm-60d0... which compares the two.

Most of exevp's comment about the Prisma schema are a non-issue given an understanding of the value it provides. But I can understand the reluctance to learn yet another DSL. But in my experience, if you've worked with relational databases, it's a breath of fresh air to be able to define your database schema with it.