Using multiple GraphQL servers with one, shared service



Hello Prisma forum! :slightly_smiling_face:

I’m fairly new to Prisma ecosystem and I’m just trying it out and checking if it can be a fit for a project I’m working on. So far I’ve played around with graphql-yoga and prisma-bindings and I love how easy it is to have them working together. Great stuff!

For the upcoming project my infrastructure will consist of two different server side API’s with different business logic. However, both of them will be connected to one dataset with same data. What I would imagine would be the solution is to create two graphql-yoga servers, connect them through prisma-bindings to 1 service = profit!

As far as I understand I have to have prisma-binding’s for each API, which means I need to maintain data models + database schema in both API’s. Obviously, it’s not ideal and co go out of sync very quickly and preferable solution would be to extract that somehow.

Is there any tool or approach which could help me maintaining one database schema which then i could connect two different API’s?

Thanks in advance!


Hey @wojciech and welcome to the Prisma Forum :wave:

You can connect many GraphQL Yoga servers to the same Prisma API.
Whenever you change the datamodel of your Prisma service, you need to regenerate the Prisma bindings that is used in your GraphQL Yoga servers.

You can run graphql get-schema and/or graphql codegen to do so. Here is a simple example that uses post deployment hooks to run these commands:

You don’t have to use hooks, you can also run the commands directly.
You will need to adjust the example to your setup with multiple GraphQL Yoga servers :slight_smile:


Hi @nilan, I’m sorry to follow up with a different but related question. Is it possible to connect one GraphQL Yoga server with multiple Prisma APIs? Thanks.


Thanks @nilan, i didn’t know about the graphql get-schema and that could work. I just need to make sure that I have that in a flow somewhere so I wouldn’t have yoga servers out of sync. I would imagine that yoga servers would be in separate repositories so hooks on post-deploy wouldn’t work.


Hey, sure that’s possible! Have a look at how a prisma-binding instance is usually hooked up to the GraphQL Yoga server. Here I’ll show the JavaScript case, it works a bit differently for TypeScript.

// 1
const db = new Prisma({
  typeDefs: 'src/generated/prisma.graphql',
  endpoint: process.env.PRISMA_ENDPOINT,

// 2
const server = new GraphQLServer({
  typeDefs: './src/schema.graphql',
  context: req => ({ ...req, db }),

What happens here?

  1. We initialize an instance of prisma-binding using the Prisma constructor
    • We are passing in the endpoint where the queries will be sent to
    • and the type definitions from the previously generated schema prisma.graphql of the Prisma API.
  2. We initialize a new instance of graphql-yoga using the GraphQLServer constructor
    • We pass in the type definitions that we defined ourselves in schema.graphql,
    • the resolvers we implemented ourselves (with the help of prisma-binding),
    • and, now comes the interesting part, we attach the prisma-binding we created in 1. to the context of the request, using the db identifier (arbitrarily chosen in 1.).

So, how can we attach one or more Prisma bindings to the context?

Well, we repeat step 1. once for every Prisma API, and attach all Prisma bindings to the context in step 2. Quick example:

// 1a
const user-data = new Prisma({
  typeDefs: 'src/generated/user-data.graphql',
  endpoint: process.env.PRISMA_USER_DATA_ENDPOINT,

const email-data = new Prisma({
  typeDefs: 'src/generated/email-data.graphql',
  endpoint: process.env.PRISMA_EMAIL_DATA_ENDPOINT,

// 2
const server = new GraphQLServer({
  typeDefs: './src/schema.graphql',
  context: req => ({ ...req, user-data, email-data }),


Yes, that could be a post-commit hook on the version control level, or your CI environment. :slight_smile:


thank you @nilan, this is totally the beauty of GraphQL and Prisma.