What are the edge cases that make Prisma necessary?


#1

When reading threads comparing Prisma with the Framework, a common theme I see is that while the Framework is easy to use, it supposedly has some show stopping limitations - some fundamental flaws that would halt a “real world” app in its tracks, and facilitate a switch to something like Prisma. This perception seems to run so deep that it’s apparently shared by the developers themselves, who recommend using Prisma over the Framework when possible.

And yet, after months of developing a robust e-commerce oriented application on the Framework, I’ve yet to run into any issues like this, leading me to wonder - when and why is Prisma necessary? Maybe I’m missing something huge, but here’s how the pros list looks like for me:

Framework:

  • No need to host, manage, monitor, secure, or version servers or databases
  • Any custom functionality can be provided via custom resolvers or subscriptions
  • One line deployment through a CLI

Prisma:

  • ???

Maybe the docs just do a poor job of explaining this, but I don’t really understand what the hype is about - Prisma seems a whole lot of effort for slightly more granular control over data. Can someone clarify what these Framework’s show stopping issues are?


#2

I would like to know this too.


#3

This is a great question, and I hope we see a great ensuing discussion! I don’t know enough about Framework, but I’m running an image server with Prisma where I need access to the metal (for C libs) that can process images. Without going micro services, is that something the Framework can do?


#4

As far as I can tell, anything that Prisma can do, the Framework can do, because Prisma doesn’t really give you any new capabilities - it just lets you choose your “stack” more freely than you could otherwise. Both give you the opportunity to inject custom code when data is queried or mutated, so if you need to call C code, you can do so, assuming you’ve got a Javascript wrapper for it.


#5

How would you call C code within the GC Framework app?

With Prisma, since you control the server layer, you can run any arbitrary code. You asked for limitations, and unless I’m mistaken about GCF (and I very well may be), this would be one.


#6

I suppose you technically can’t, but I wouldn’t necessarily consider that a limitation - why would one run C code directly in their database server anyway? Since it sounds like you’re going to be doing computationally intensive work, I would outsource that to a specialized server or cloud function instead of trying to run it on the “main” server, and hook it up via subscriptions. Said specialized server/function can be called by the framework, and can be given a root token to mutate the framework DB when it’s done, and never need to hold up the main server.

In all fairness, you did say you didn’t want to use microservices, in which case, sure, I suppose Prisma might be a better fit for you.


#7

If the solution is always “microservices all the way down”, then sure. But microservices come with a high monetary cost. I have a DO droplet for $10/month that manipulates images, runs Prisma to track the image meta data, and serves the GraphQL server/endpoint in a reasonably scalable VPS.

Anyway, I don’t mean to hijack the thread. I look forward to hearing from others!


#8

Hi @arty,

that’s a great question!

On a high-level, you can somewhat think of the Graphcool Framework and Prisma like this: The Graphcool Framework is a ready-made car, Prisma the engine that powers the car.

The GCF is a car that you as a customer can just start driving. Doing so, you’re very much limited to everything the car comes along with, its colour, shape, seating, tires, rims, cup holders and any other tiniest detail - you’re getting an entire car!

Prisma on the other side is the engine that powers the car. By making Prisma available as a standalone open-source technology, we’re not providing any more a ready-made car. Instead, we’re providing developers the right tool to build their own awesome cars, exactly tailored to their use cases.

We understand that this shift in thinking can be a bit off-putting at first for developers who “just want a car” (building a car just from an engine is quite a bit of work). This is why we’re providing lots of additional tooling in the GraphQL open-source ecosystem (such as graphql-yoga, graphql-import and Prisma bindings) that make the experience of setting up and deploying a GraphQL server powered by Prisma at least as friendly as spinning up a new GCF instance (have you tried the GraphQL boilerplates yet?).

Most developers we have talked to about Prisma so far enjoy the switch to this new stack and the flexibility that comes along with it, lots of them even say that it’s saving them a lot of time on the long-run!

It supposedly has some show stopping limitations - some fundamental flaws that would halt a “real world” app in its tracks, and facilitate a switch to something like Prisma

The GCF is definitely able to handle real-world use cases (as you experience yourself in building a production e-commerce app). It’s just in the very nature of a Backend-a-a-Service that it provides an opinionated stack that doesn’t offer many choices to backend developers for how they want to structure their application.

The obvious examples are the following:

  • You can’t build your application in the programming language of your choice - the GCF is implemented in Scala so that’s what your backend will be using under the hood! You can to some degree choose between languages when implementing business logic with serverless functions (managed functions are only supported in JavaScript, but using webhooks you can also invoke languages written in a different language).
  • When using the GCF, you don’t have a lot of control regarding infrastructure and tooling but are limited to the choices already made by the GCF. This applies to areas like deployment tools, CI/CD, integration testing, analytics and a lot more…
  • The GCF runs on MySQL databases. Whilst relational databases are great for certain applications, they’re definitely not a silver bullet and various other kinds of databases are more suited for certain applications and use cases (that’s why special kinds of databases like time-series databases, geodatabases or graph databases exist).
  • In general, the architecture for server-side logic is a lot more flexible and powerful when choosing the Prisma stack. You can for example build your own permission system which is not possible with the GCF where you’re bound to using the opionated permission queries.
  • Another important point is the future-proofness of the stack. The GCF has made an initial choice of technologies it is based on - but as the tooling and infrastructure space is changing so quickly and the next revolutionary tool might be just around the corner, the GCF users won’t be able to benefit from it when it comes out (but at the least would have to wait for the GCF to adapt it, if that happens at all). One example of that is schema stitching: It would be very difficult for the GCF to support an easy way for developers to stitch together their own GraphQL API with other ones (and if it were supported, the way of doing this would be very likely to be quite complex and require you to learn the required steps rather than taking advantage from existing open-source tooling).
  • Finally, the gained flexilibity also shines in various other aspects and leads to better development workflows. Areas like local development, testing, debugging, logging, performance monitoring and profiling will become a lot easier when you have the entire control over your stack.

While these limitations may not be relevant to your specific use case, we have found that they are crucially important for many developers, especially working in larger teams and organizations.

I hope this helps understanding a bit better the motivation behind Prisma. I’d definitely encourage you to check it out in more detail to build your own awesome car :slight_smile:

Edit: To learn more about what building GraphQL servers with Prisma looks like and how to leverage tooling like graphql-yoga and prisma-binding, I encourage you to check out the following tutorials:


#9

Thank you for that remarkably detailed comparison, @nikolas! I think this will be a great resource to help people decide which one they want to use :slight_smile:


#10

Pretty much all of the points besides the final one are implied by “opinionated” framework. Any chance you don’t do local development, testing, debugging, etc in not seeing downsides to graph cool?


#11

Would starting with graphcool and then migrating be okay?