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-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:
- 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
Edit: To learn more about what building GraphQL servers with Prisma looks like and how to leverage tooling like
prisma-binding, I encourage you to check out the following tutorials: