Demystifying GraphQL Schema Stitching: Connecting GraphQL Schemas for Powerful APIs

#api #graphql #graphqlapi #apigateway #composable #architecture #web #frontend
Github Repository - github.com/techforum-repo/you...
GraphQL is a query language and a technology for APIs, created by Facebook in 2012 and made open-source in 2015. It lets clients request exactly what they need from an API, nothing more, nothing less. The 'QL' in GraphQL stands for 'query language.' It's an alternative to REST, which is another common method for building APIs. Basically, GraphQL allows for more structured and efficient data queries.
Why do developers like to use GraphQL?
GraphQL is different from a RESTful API in some key ways. With RESTful APIs, you often don't know what data you'll get without specific documentation. But with GraphQL, you can specify exactly what data you need and receive just that, all in one API request instead of several.
Another cool feature of GraphQL is its introspection ability. This means you can understand and work with an API programmatically, even if it's your first time using it.
The biggest advantage of GraphQL is that it gives frontend developers more control over data. Whether they're working on a mobile or web app, they can select data more efficiently.
And there's more. GraphQL is composable. This allows developers to combine multiple GraphQL APIs into one unified API.
At the heart of every GraphQL API is its schema, which defines how data is structured and accessed
Sample Graphql api -
studio.apollographql.com/publ...
__schema {
queryType {
fields {
name
type {
name
kind
ofType {
name
kind
}
}
}
}
}
}
Schema Stiching:
Schema stitching is like creating a big puzzle from smaller pieces. It involves combining multiple smaller GraphQL schemas from different sources into one large schema, known as the gateway. This gateway acts like a proxy layer that clients can use to make requests.
Here's how it works: When a client sends a request to the gateway, the gateway figures out which part of the combined schema, or subschema, is responsible for the requested data. It then forwards the request to the appropriate subschema.
Each subschema handles its part of the request, and the gateway brings all these pieces together. It sends the complete data back to the client, which remains unaware of the behind-the-scenes process.
With schema stitching, developers can also expand or modify the existing structures and functions of the schema. This makes the client experience seamless, as they can access a wide range of data through a single, unified schema.
Benefits of schema stitching in GraphQL:
Modularity: Schema stitching lets you break down your API into smaller, manageable services.
Code Reusability: You can reuse and extend existing schemas, which reduces duplication and supports a more modular development approach.
Seamless Client Experience: Clients get to interact with just one schema, even though it's made up of many.
Simplified Data Fetching: Instead of sending multiple queries to various services, clients can get all the data they need with just one query to the unified schema.
Improved Maintainability: Each service within the schema can focus on what it does best and evolve on its own.
Easier Integration: Stitching schemas from different sources, like third-party APIs, becomes much simpler. The unified schema takes care of the complex parts of communicating with multiple services, making integration a breeze.
The custom resolvers are needed when using stitchSchemas in GraphQL:
Handling Complex Queries
Linking Data Across Services
Data Transformation and Aggregation
Implementing Authorization and Access Control
Consistent Error Handling and Logging
Extending or Modifying Schema Functionality
Performance Optimization
In short, while stitchSchemas does a lot of the heavy lifting in combining schemas, custom resolvers give you the flexibility to handle more complex tasks and changes that automatic stitching can't cover.

[@rajat3174]

very intresting and informative.

[@MG-wx8yx]

It's very informative and it helped me a lot. But from 14:06, you skipped then most important part in Schema Stitching, querying data from another service using id from another service linked to that service...example using userId to query posts or post with the user information who posted the post based on the userId in the post, can you make another video just for that? I'll appreciate it. Liked and subscribed.