CODEWITHSUNDEEP
graphqlprisma
NikxDa
NikxDa

Reputation: 4187

Why use Prisma in a backend environment?

After learning about GraphQL and using it in a few projects, I finally wanted to give Prisma a go. It promises to eliminate the need for a database and it generates a GraphQL client and a working database from the GraphQL Schema. So far so good.

But my question is: A GraphQL client to me really only seems useful for a client (prevent overfetching, speed up pages, React integrations, ...). Prisma however does not eliminate the need for business logic, and so one would end up using the generated client library in Node.js, just to reexport a lot of the functionality in yet another GraphQL server to the actual client.

Why should I prefer Prisma over a custom database solution? Is there a thought behind having to re-expose a lot of endpoints to the actual client?

Upvotes: 6

Views: 3542

Answers (2)

Hemant Parashar
Hemant Parashar

Reputation: 3774

Even I had similar questions when I started learning graphql. This is what I learned and realised after using it.

  • Prisma acts as a proxy for your database providing you with a ready to use GraphQL API that allows you to filter and sort data along with some custom types like DateTime which are not a part of graphql and you'd have to otherwise implement yourself. It's not a GraphQL server. Just a layer between your database and backend server like an ORM.

  • It covers almost all the possible usecases that you might have from a data model with all the CRUD operations pre-defined in a schema along with subscriptions, so you don't have to do all that stuff and focus more on your business logic side of things.

  • Also it removes the dependency of you writing different queries for different databases like Sql or MongoDb acting as a layer to transform it's query language to actual database queries.

  • You can use the API(graphql) server to expose only the desired schema to the client rather than everything. Since graphql queries can get highly nested, it may be difficult and tricky to implement that which may also lead to performance issues which is not the case in Prisma as it handles everything itself.

You can check out this article for more info.

Upvotes: 7

nburk
nburk

Reputation: 22731

I work at Prisma and would love to clarify this!

Here's a quick note upfront: Prisma is not a "GraphQL-as-a-Service" tool (in the way that Graphcool, AppSync or Hasura are). The Prisma client is not a "GraphQL client", it's a database client (similar to an ORM). So, the reason for not using the Prisma client on the frontend is the same as for why you wouldn't use an ORM or connect to the DB directly from the frontend.

It promises to eliminate the need for a database and it generates a GraphQL client and a working database from the GraphQL Schema. So far so good.

I'm really curious to hear where exactly you got this perception from! We're well aware that we need to improve our communication about the value that Prisma provides and how it works. What you've formulated there is an extremely common misconception about Prisma that we want to prevent in the future. We're actually planning to publish a blog post about this exact topic next week, hopefully that will clarify a lot.

To pick up the concrete points:

  • Prisma doesn't eliminate the need for a database. Similar to an ORM, the Prisma client used to simplify database access. It also makes database migrations easier with a declarative data modelling and migrations approach (we're actually currently working on large improvements to our migration system, you can find the RFC for it here).
  • Another major benefit of Prisma is the upcoming Prisma Admin, a data management tool. The first preview for that will be available next week.

Upvotes: 15

Related Questions