On GraphQL Schema Stitching & API Gateways

API Gateways

type User {
name: String
posts: [Post]
}
type Post {
title: String
author: User
}
# users.schema.sdl
type User {
name: String
postIDs: [ID]
}
# posts.schema.sdl
type Post {
title: string
authorID: ID!
}
query WhatWeWouldHaveLovedToDo {
currentUser {
posts {
title
}
}
}
query WhatWeEndUpHavingToDo {
currentUser {
postIDs
}
}
query AndThen($ids: [ID]) {
posts(ids: $ids) { title }
}

Classic Schema Stitching

Not really a GraphQL problem

My Question

  • Make schema changes at the service level
  • Extend the gateway schema with links to the new changes

Hard Mode

Centralizing the Schema

  • Define the schema using the SDL at the gateway.
  • Instead of stitching and merging together schemas, have great tooling to enable importing types / fields from certain schemas.
  • Design the gateway in a way that minimizes the amount of business logic. That’s a hard one, the “glue” code we talked about needs to exist somehow, and it’s hard to avoid that code to become more than just glue.
  • Possibly extend the SDL syntax with directives that allow connecting services together. Auto generate as much code as possible to avoid custom business logic.
  • Services can define their interface with anything: grpc, REST, GraphQL, it doesn't matter, we can build the right adapters at the gateway level.
  • The resulting IDL is found in a single place, it is easier to track down issues, and to view the final state of the schema.
  • There’s only one thing to change to make changes to the schema, it’s also more obvious to see what effect the change will have.
  • Sharing types, conflicting types are well handled as we control the whole schema. The lack of namespaces makes schema merging tricky, although there are solutions to this.
  • Multiple teams working on a large schema, we lose the autonomy of a fully decentralized schema. As a solution: we can possibly detach part of the schema into their own service, but always manually import those types into the gateway, no automatic stitching.
  • We don’t necessarily solve the “business logic at the gateway” problem. As we build this gateway, we have to get the API just right so that the code base can’t evolve this way.

--

--

--

#GraphQL Enthusiast, Speaker, Senior Software Developer @ Netflix 📖 Book is now available https://book.productionreadygraphql.com/

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Why unit testing is not enough when it comes to microservices

How to Stop Worrying and Start Opensource (with a good deploy, CI, and demo)

Quickly make an API with Auth

6 Design Principles for your HTTP APIs

“Why” should I write good commit messages?

The coolest things about Go Language

Passing the Google Cloud Data Engineer Exam

The simple cure for AWS Lambda lock-in fear

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marc-André Giroux

Marc-André Giroux

#GraphQL Enthusiast, Speaker, Senior Software Developer @ Netflix 📖 Book is now available https://book.productionreadygraphql.com/

More from Medium

Latest Improvements To Duda’s Runtime Cache Service & Website Performance

Service Worker in Browser Extensions

[Tech Blog] Augmenting GraphQL APIs via schema extensions

Things We’ve Learned While Working with GraphQL