What the hell is Prisma, the GraphQL thing?
With the launch of Prisma Cloud today, the ecosystem of products around GraphQL can feel a little muddled. In this post, I’ll try and clear-up what’s what by explaining how Prisma fits into our stack.
For the sake of disclosure: I work for my girlfriend, my users, and my cats, but not for Prisma or any other company named here.
How we got here
To understand what value Prisma brings, we’ll need to understand what came before, the problems it had, and how Prisma tries to solve them.
A generic web application stack
This is a generic web app:
When the user wants to read about rare catnip, the client sends a request to the server’s
/catnip endpoint, the server asks the database for data, combines that data with formatting, etc., then sends it to the client. No big deal.
The ‘sghetti Stack
Servers add end points as they grow, and eventually, you might have a lot of endpoints communicating with a lot of parts of your app. A lot of people are saying this is called the Spaghetti Stack.
The GraphQL Stack
To save you from endpoint hell, Facebook invented GraphQL:
Instead of sending requests to REST endpoints, now your clients can send their requests to a GraphQL server who knows where you keep all your datas, how tables relate to each other, etc.
The client still requests complex combinations of data from the server, but thanks to GraphQL, they’re all sent in a neat, orderly fashion instead of being sent all willy-nilly.
The GraphQL stack isn’t all sunshine & rainbows, though. Teaching the GraphQL server where all of your data is & how to fetch it (via a ‘GraphQL schema’ and ‘resolvers,’ respectively) can get tricky, which puts a damper on GraphQL’s promised simplicity.
GraphQL? There’s a SaaS for that.
Well, technically, a GraphQL BaaS. Several startups built offerings atop the GraphQL architecture that gave users the client-side bliss of GraphQL without the (arguably) complex task of setting-up a database, server, etc.
Some GQLaaS services have already closed-up shop. One of the first GQLaaS companies, Graphcool, became something of a staple in the open source community surrounding GraphQL.
The BYODB stack
So, that’s neat, but what if you love SQL, dislike BaaS, and don’t want to worry about setting-up your own GraphQL server?
Hey, great news: that’s where Prisma, the new offering from the Graphcool team, fits. Prisma, along with the open-source PostGraphile (né PostGraphQL), and AWS’ nascent AppSync, all sit at a sort of hybrid space between DIY and full-blown BaaS:
Quick note: AWS AppSync has more BaaS-style features than Prisma or PostGraphile, and of the three, is the only one built to be used as a full-blown BaaS, but for the purposes of this discussion, I’m just focusing on AppSync’s data layer functionality.
How do they work?
You can think of these products as a sort of auto-generated API for your database. They provide a GraphQL endpoint through which to access your data, as well as handy filtering capabilities so your client can slice & dice data without having to write a ton of boilerplate queries.
Your clients query that endpoint, and Prisma / AppSync / PostGraphile return the data. Crucially, you have the option of short-stopping queries & doing stuff in-flight or in-response (e.g., input validation, PubSub alerts, etc.).
AppSync lives entirely in the cloud. PostGraphile is self-hosted only, and Prisma can be self-hosted or cloud-hosted.
Learning your database
PostGraphile will learn your existing PostgreSQL database, while Prisma and AppSync both exercise more control over your database schema (and, therefore, require a bit more work to set-up with existing databases).
Prisma & AppSync, in fact, will create tables in your database on your behalf, allowing you to write only a simple GraphQL schema, and spare you some of the trouble of database management.
Extra stuff like authentication, email, etc.
Of course, there are a lot of ancillary functions you’ll need for an app (authentication, authorization, etc.). In the case of AppSync, these features are baked-in via integrations with other AWS services (Lambda & Cognito).
With PostGraphile and Prisma, though, you’ll likely be setting up your own GraphQL server. But, (a) both products solve a lot of the pain points of running a GraphQL server, and (b) with cool stuff like Apollo’s Schema Stitching, it takes just a few dozen lines of code to mesh several GraphQL schemas into a single unified endpoint.
At the moment, PostGraphile works only with PostgreSQL, AppSync only works with DynamoDB, and Prisma only works with MySQL. Of these, Prisma is the only one (AFAIK) to have plans for other databases.
So there you go: Prisma talks to your database so you don’t have to.
Since you’ll need to manage your own database, and (probably) set up your own GraphQL server, the product isn’t as hands-off as Graphcool or other BaaS. But the ability to host your own service, bring your own database, and SQL your own SQL will definitely give plenty of users reason to consider giving Prisma a shot.
I hope this cleared-up a bit of the mystique around products like Prisma & their use cases. If not, post a question / personal attack in the comments!