If you’ve been looking at GraphQL in the last couple of years, you have probably heard two words being used: schema stitching and federation . Maybe you dug a bit deeper or maybe you just filed them on a shelf in your mind with the label “I’ll figure this out later”.
Well, “later” has arrived, and in this blog post, I’ll try to introduce you to the topic.
What is GraphQL?
Very briefly, since this has been told so many times… GraphQL Foundation gives a short description that I think encapsulates all the essential things:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools”.
Since Facebook open sourced GraphQL in 2015, the concept has started gaining momentum. And after 2018, when GraphQL Foundation was officially established, the development and community support for the language has soared.
While organisations started battle testing GraphQL in production for their use cases, they discovered that GraphQL has begun suffering from the “monolith” problem, especially in large organisations. The graphs started growing in size and became more and more complex. At the same time, they often contained data from multiple business domains and became harder to use, maintain and extend.
How can we untangle that complexity?
Just as with monolithic architectures that are often split into microservices, the GraphQL community adopted a similar approach.
GraphQL Foundation states that:
“With GraphQL, you model your business domain as a graph by defining a schema; within your schema, you define different types of nodes and how they connect/relate to one another”.
That’s a great approach, isn’t it? But it also means that whenever domains intertwine or should be looked at together, you have a problem.
That problem currently has two main solutions:
- Schema stitching, or
- GraphQL Federation.
What is schema stitching?
Schema stitching is a method for combining various GraphQL schemas into a single, unified schema. It allows you to merge schemas from disparate sources, such as APIs or databases, into a unified GraphQL schema that users can query. You may also utilise schema stitching to add new fields or functionality to an existing schema. The stitched schema acts as a gateway to access the underlying services.
A few key points to remember:
- It is typically done at the schema level, where schemas are merged to create a single schema.
- Schema stitching can be done manually, by using libraries like
graphql-toolsorgraphql-stitchor by using Tyk’s Universal Data Graph. - It requires explicit knowledge of the underlying schemas and their types to resolve conflicts or avoid naming collisions.
What’s GraphQL federation?
GraphQL federation is a method for developing a distributed GraphQL system using a federated architecture. It allows you to build a composite graph by integrating numerous GraphQL services into one. Each service maintains its section of the overall schema, known as a “subgraph,” and the federated schema manages communication between these subgraphs.
Key points to remember:
- It is based on the concept of a federated schema, which is composed of multiple independently deployable GraphQL services.
- Each service is responsible for its domain and exposes a subset of the overall schema.
- A gateway layer is used to compose the federated schema and handle the execution of queries across the services – that gateway is usually Apollo.
- Federation provides a more decentralised approach than schema stitching, allowing teams to work independently and own their services.
- It provides built-in features for schema composition, including type extensions, directives, and entity resolvers.
Which one should you go for?
It would be so amazing if the answer to this question were just one sentence! It is not, but I will try to give you some ideas on what questions you should be asking yourself when making a decision:
- How fast do you need to build your service? Generally, schema stitching is a simpler and faster approach, especially if your architecture is not yet complex, but still with services that are tightly coupled with each other.
- What’s the level of GraphQL knowledge in your team? GraphQL Federation has a steep learning curve, and getting it right might be difficult if you’re only starting out with GraphQL in your organisation.
- What’s the organisational structure of your team? Federation can work great if your teams are independent, mature and have all the necessary domain knowledge to “own” a graph. If you only have a few development teams and your APIs are still designed in a central place, then federation might be too much, and you should look at stitching first.
- And the elephant in the room – how much are you looking to spend? This could be a series of posts, but in today’s economy, you or your managers will definitely ask this question. Federation has been developed and maintained by Apollo, so if you’re rolling it out, there will be an invoice coming.You could stick with Apollo only, but at some point, you will realise that you still need an API management platform to reign in the chaos, especially if your services are external-facing, not only internal. In that case, you should give schema stitching a good look, particularly Tyk’s Universal Data Graph. It already sits in Tyk’s API management solution, so you get all the benefits of that anyway.
And last but not least – understand your requirements! They should have the biggest impact on your decision in the debate.
If you’d like to speak to one of our expert engineers about choosing between schema stitching and federation for your GraphQL implementation, get in touch here.
