Why does Prisma run in a Docker container instead of being a simple library?


#1

Hi!

Why does Prisma run in a Docker container, instead of being a simple library such as Mongoose or any other ORM?

Thanks!


#2

Hi Guido, I think that’s an excellent question. I had the same one. I come from a Java ORM background where the ORM tools are all libraries in the form of JARs, like Hibernate. It seems that running a Prisma Server adds another layer to the technology stack, which by default adds another layer of complexity. Maybe in this world of Kubernetes, scaling is easier so adding another layer to the stack does not pose a scaling issue?

The recommended Prisma architecture for applications is really two GraphQL servers talking to each other via the Prisma Client. The Application API GraphQL server is what your client talks to. That’s an important key here in the design. This application architecture is for apps where the client developers want to talk to a GraphQL API. We, as server developers, are “resolving” the GraphQL request from your client app into yet another GraphQL request to the Prisma Server via the Prisma Client.

In addition, the Prisma Server exposes every possible way to access and write data for the entire database via GraphQL. You certainly do not want to expose that to a client directly.

I suppose there could be many ways to consolidate the stack and reduce what seems like an extra layer in the server topography. At this point, I’m assuming the reason why two GraphQL servers exist is because it’s the only way to resolve one GraphQL request and transform it into another one with the existing Prisma Client technology. Another theoretical solution would be for the Prisma Client to talk to the database directly, in the way that a Java-based Hibernate Driver talks to the database directly.

Looking forward to hearing your thoughts.


#3

See:


#4

Hey @guidolodetti, that’s a great question and indeed a confusion that many Prisma newcomers have. I’ve recently written up a Gist where I’m also answering exactly this question:

"The main reason why the Prisma server exists is because of Prisma’s history and the fact that it was born out of Graphcool (which is a Backend-as-a-Service). While we see a lot of potential value in using this additional server component between your database and application server, we definitely acknowledge that it can be confusing for people starting out with Prisma that are ‘just looking for an ORM’. That’s why we are currently working on a version of that will make it possible to use the Prisma client without running an additional Prisma server (the very rough timeline for that is some time around April/May).

Nevertheless, we are going to continue to build out the Prisma server as we think that it can add a lot of value in the future, especially for more advanced/enterprise use cases. For example, we’re planning to add caching and security capabilities to it. Having this extra layer that sees (and routes) all your database requests (especially if it’s connected to multiple databases) is a great place to implement things like audit logging or other features that are critical in the enterprise world. Also note that the Prisma server is horizontally scalable, so it can be deployed as a multi-node cluster as well.

Benefits that the Prisma server buys you today already e.g. are the subscription API or that it enables connection pooling when used in the context of serverless functions."

As stated in this response, we’ll soon have a version of Prisma that will allow you to use the Prisma client with all its benefits, without running the extra server component.

I also quickly want to pick up @jonathan.graf’s comment about running two GraphQL servers. The fact that Prisma servers currently are based on GraphQL is considered an implementation detail of the architecture. Prisma currently uses GraphQL as a wire protocol, but as a Prisma user that’s not really something you should care about. What you should care about is the API of the Prisma client, since that’s the part of Prisma you’re interacting with to access your database! GraphQL has shown to be a fantastic choice as a wire protocol, however it might be replaced with something else at some point, that’s why we consider it an implementation detail that should be irrelevant for Prisma users.


Declarative access to Data Layer GraphQL API
#5

Thanks for looking into ways using Prisma without docker… its really annoying