Are you ready to get to grips with GraphQL schema stitching? Whether you’re after an introduction to schema stitching, wondering about the finer points of schema stitching vs federation or trying to find out which GraphQL tools schema stitching is easiest with, we’ve got you covered.
GraphQL took the industry by storm as a query language for APIs with its complete and understandable API data descriptions. It empowered clients to ask for just what they needed and nothing more, with a schema describing the shape of the available data.
Now, schema stitching means you can combine multiple schemas into a single endpoint. With Tyk, for example, you can stitch schemas from existing RESTful and GraphQL endpoints quickly and easily, creating a single endpoint for queries across multiple schemas. Let’s dive into the details.
What is schema stitching?
What is schema stitching in GraphQL? Essentially, it’s a way of enabling a single query to span multiple GraphQL schemas. This can enhance performance by reducing the need for multiple roundtrips. It also has benefits in developer experience (DX) terms. After all, who wants to maintain and interact with more APIs than is absolutely necessary?
The need for schema stitching in GraphQL
GraphQL stitching comes into its own when combining smaller services to deliver a larger system offering. Just as an API gateway for microservices delivers security and standardisation (and much more), adding schema stitching GraphQL becomes even more valuable to your business. Clients can make a single call, with the gateway putting in the legwork and returning a response containing data gathered from multiple subschemas. This is particularly useful when your underlying services aren’t all GraphQL.
There’s a win for developer efficiency here – each team can maintain its schema(s) based on its particular area of work and expertise. With an API gateway providing a uniform frontend irrespective of what’s happening behind the scenes, efficiency is delivered at the client level and across dev teams.
How schema stitching works: the process of schema stitching
Schema stitching in GraphQL combines multiple schemas into a single endpoint, neatly creating a unified GraphQL schema. Let’s break this down a bit.
Delegating requests to the appropriate subschema
Introspection ensures that requests can be delegated to the appropriate subschema. It explores the schema structure and directs requests accordingly.
Combining resolved fields from various schemas
At the other end of the process, after handling type name collisions and associating and adding fields and types, GraphQL stitching enables data from different subschemas to be resolved into a single response.
GraphQL schema stitching vs federation
It’s worth exploring GraphQL schema stitching vs federation quickly here. One of the many benefits of Tyk is that it makes both of these relatively simple to achieve.
You can use stitching and federation to deliver multiple services through a single endpoint – the implementation differs. The key difference between GraphQL stitching and federation is that you must define the stitching yourself in the gateway. This is great if you have a gateway that connects to underlying services that are not GraphQL – for example, if you have a gateway connected to a REST API.
With federation (which you can only use for GraphQL services), you tell the gateway where to look for different objects and which URLs they live at. Then the gateway stitches everything together automatically, using subgraph metadata.
The key benefit of GraphQL federation vs stitching is that federation is lower maintenance and provides plenty of flexibility. These benefits are why tooling such as Apollo federation vs schema stitching and Tyk GraphQL federation has attracted such keen interest.
Use cases and examples
Various use cases suit Apollo schema stitching, AppSync schema stitching, Hasura schema stitching, etc. Naturally, we will focus here on the use cases for GraphQL and Tyk.
With Tyk, you can bring full lifecycle API management to GraphQL, enjoying seamless introspection while fully controlling your schema stitching (or federation, if that’s what you need). Tyk approaches this from an API-first, developer-centric perspective, essentially turning GraphQL into a single pane of glass for your entire organisation
US-based home and auto insurance provide Branch shows how well this can work. Branch uses Tyk to provide full API management for GraphQL, opening its platform to insurance partner affiliates. By implementing full lifecycle API management alongside Tyk’s GraphQL developer portal, Branch can work more efficiently with affiliate partners, offer better services to end consumers and gain more revenue. There are wins at every stage of the process.
Setting up a project for schema stitching
Setting up a project for schema stitching is not without cost in terms of time and resources. However, GraphQL schema stitching can be surprisingly speedy – depending on your tools. This makes it a great choice if you’re setting up a minimal viable product and for larger projects.
To get started, you’ll need to decide which GraphQL tools stitch in a way that best suits your needs. Then, whether you’re using Apollo Server schema stitching, Tyk or an alternative, it’s time to set up your project.
Using Tyk’s Universal Data Graph, you can build your schemas using RESTful and GraphQL services and infrastructure, all with no code and without needing to change your backend. You don’t need to build a whole new GraphQL backend ecosystem or worry about supporting GraphQL and your existing RESTful API services and infrastructure. Handy, huh?
To set up a schema with Tyk, you simply create your schema, set your authentication, map your data to your schema from your RESTful, GraphQL and/or Kafka data sources and save the endpoint. You can do this as often as you need, all through the Tyk Dashboard and with different teams setting up different schemas to suit your needs. These are the blueprints of your data structure, defining what data can be requested and how they’re interconnected.
To stitch the schemas together, you introduce them to Tyk’s Universal Data Graph. This allows you to combine data from disparate sources into one coherent API endpoint without writing a single line of code.
Once you’ve stitched your schemas together, you can test your new GraphQL endpoint within Tyk to ensure everything works as expected. You send a query, and Tyk will interpret it, gather the data from the relevant sources, and return a GraphQL response. Voilà! You’ve just stitched together your GraphQL schemas.
Merging
GraphQL schema merging is not the same as schema stitching. Stitching builds a proxy schema over the top of the subschema APIs to create a unified endpoint. Merging, on the other hand, creates a single executable schema by consolidating type definitions and resolvers from local schema instances.
There are some issues to look out for here, particularly GraphQL federation. Subgraphs with the same name for shared types (objects, inputs, enums, etc.) may cause errors when schemas merge into a federated supergraph.
Schema merging can also fail, depending on the order of resolving subgraph schemas, if individual subgraphs aren’t normalised before attempting a merge. The key to success here is choosing the right GraphQL tools for stitching, merging, federation and more.
Benefits for backend development
Using GraphQL schema stitching delivers a range of benefits for backend development. As mentioned above, it delivers the flexibility for different teams to maintain different subschemas. This degree of modularity can encourage code reusability and simplify collaboration within and between teams. It can also support scalability, as different parts of the GraphQL API can scale at different speeds and thus respond flexibly to changes in need (for example, if one part of your application experiences higher traffic than others).
Schema stitching effectively knits different microservices together into a single endpoint, so it needs factoring into your microservice gateway and access pattern planning. This loose coupling can be handy for both backend and frontend development, delivering greater efficiency. The same is true of third-party API integration using a unified GraphQL schema.
GraphQL stitching can also be beneficial when integrating legacy systems and data sources using different architectural constraints (such as REST), by allowing for seamless integration without having to rewrite the backend completely.
There is a performance benefit to all this, as schema stitching can reduce the need for multiple API calls. The fact that schema stitching underpins GraphQL federation adds to the benefits of using it too.
Benefits for frontend development
The benefits don’t stop with backend development. Frontend developers can enjoy some schema stitching-related wins too. The unified GraphQL schema abstracts away the complexities of dealing with a mishmash of data sources and/or microservices, making the API easier to understand and consume. This reduces the learning curve for new team members – in much the same way that Tyk does!
A stitched schema’s consistent data structure can also deliver advantages for frontend development by delivering standardisation and predictability in terms of data structure. This means that frontend developers can query and manipulate data efficiently without stressing about adapting to numerous data formats from multiple APIs.
Increased efficiency in terms of data fetching and performance can benefit frontend as well as backend developers. The ability to bring more data in fewer requests and the associated latency reduction can also improve the overall user experience.
There is also more scope for independence between backend and frontend teams with GraphQL schema stitching. The ability to make changes in the backend and tinker without impacting the exposed schema means that frontend developers can be confident that everything can continue functioning correctly even as adjustments are made. This includes handling versioning and deprecation smoothly, ensuring that the schema can evolve.
Schema stitching can facilitate easier testing and mocking, too, with frontend developers able to create mock versions of the backend API to test frontend components independently.
We mentioned easier third-party API integration above as a backend development of schema stitching in GraphQL. This can also benefit frontend developers with a unified and consistent interface across different data sources, reducing the complexity of handling multiple external APIs.
This combination of benefits means that the overall developer experience – for both frontend and backend – can be enhanced by GraphQL stitching.
What’s next?
Are you ready to reap the rewards of GraphQL schema stitching? If so, it could be time to do so with Tyk. Our open source API gateway makes GraphQL stitching, subscriptions, federation and more easy and rapid, ensuring you can achieve everything you need painlessly.
Any questions? The Tyk team is here to help, so feel free to get in touch if you want to discuss schema stitching or any other aspect of GraphQL.
