Demystifying GraphQL: Exploring Subgraphs, Gateways, and Supergraphs

What is this article about? It aims to help readers understand the fundamentals of GraphQL, covering its usage, subgraph, supergraphs, registry, and gateway all in one place. The article provides a comprehensive overview of why GraphQL is important.

What this article is NOT about? It does not delve into the implementation details or provide guidance on how to achieve specific solutions. Ample documentation is already available for those aspects.

Microservices! Microservices! A plethora of microservices! This is what we inevitably develop to meet horizontal capabilities across teams and pillars in major tech giants such as Walmart, Amazon, and Facebook.

These micro-services grow so significantly that it becomes challenging to identify if any team is duplicating work, particularly when interactions occur within the services. This situation is exacerbated by challenging-to-enforce contracts, making matters even more complicated when services vary in their usage of information sent through any API.

That necessitates the need for a solution that facilitates the centralization of APIs and provides flexibility in choosing the subset of information that an API requires!

Now imagine yourself as a developer of Product Services, where each client requests a different set of information for the same product. What you would end up doing? Would you create a new API with a contract specifying the desired output, knowing that internally, at the service layer or even further down, the same set of services being used? Or would you add some extra fields in the request and hardcode them to identify the source of request and dynamically preparing the response? Or would you send the same response to all the services, even if they are not using it, and let them filter out the relevant information themselves? Such an approach would be challenging to maintain and imagine the performance impact it will have in fetching irrelevant information.

Consider this case- Billing services requests a product price, which varies based on inventory stock. This implies that an additional hop to inventory services would be required to identify the price. Simultaneously, user services is asking for the product details that a customer ordered in the past. This case exemplifies a situation where the flow of information is bound to vary. The only feasible option is to manage it independently using some logic!

Graph query language is the solution! You bind your APIs using something called as Subgraphs, which precisely defines the structure of your API’s request and response. Additionally, you can exert control over the fields exposed by your application. A subgraph serves as the source of information for any consumer service, enabling it to request precisely the subset of information it requires- nothing more, nothing less. This eliminates surprises for consumers, ensuring the static nature of your API response. The Subgraph encompasses your request and response types, and you must define it to a primitive scalar GraphQL data type, collectively forming your Schema.

GraphQL also addresses the problem we encountered earlier — the need for an extra hop if a dynamic price is required for a product. This additional hop can be saved and will only be made if the consumer service explicitly requests a dynamic price, utilising Schema mapping. It’s as simple as lazy loading.

But wait! How does the request flow from type definition to the services? Resolvers are the ones that perform the magic for you. The mapping between types and function calls is based on type-names. GraphQL provides you with the capability to choose defaults or write your own custom GraphQL resolver.

So far, we have addressed the problem within our service. But what about centralising your services, avoiding duplicated work, blah blah blah?

With each service developing its own subgraph and working in silos, it becomes challenging to track these subgraphs, schemas, and type definitions. There needs to be a centralised registry that aggregates all these subgraphs and publishes a graph out of them. Apollo Federation provides a solution through Schema Registry, serving as a centralised place to register all your subgraphs.

Now, envision yourself as part of the service powering the UI that interacts with all services. From that perspective, subgraphs are still scattered. What if we consolidate them into a single graph that unifies the view for any consumer? One solution is to have all teams write to the same schema, but would that be an ideal solution? Naah! There needs to be a graph that amalgamates all types and fields from your subgraph schemas, along with additional information indicating which subgraphs can resolve specific fields. That’s nothing but a Supergraph.

Routing all this information requires a layer that guides the flow correctly — and that’s the role of the Gateway. Positioned in front of your subgraphs, it acts as the entry point to your supergraph, executing incoming operations across one or more of your subgraphs. It’s entirely up to you how many gateways to configure and how to group the subgraphs. However, this comes with the constraint that you cannot duplicate the schema (type names, of course) within the subgraph, allowing you to check if a schema definition already exists!

I agree that it doesn’t entirely solve the problem of duplication, but to some extent, if standardised, it can help reduce it.

Concluding this exploration, we’ve delved into the realm of GraphQL, dissecting its components from subgraphs to supergraphs, Schema Registry, and the crucial role of the Gateway. As we navigate the landscape of API development, it’s evident that GraphQL offers a versatile and efficient solution for managing and unifying data across diverse services.

In closing, the adoption of GraphQL brings not only enhanced control over data requests and responses but also a structured approach to handling complex architectures. By leveraging GraphQL’s capabilities, developers can streamline communication between services, mitigate redundancy, and provide a more cohesive experience for consumers.