GraphQL Federation Architecture: Open/Closed Principle & Project-Based SuperGraphs

Recently, I discussed with one of our customers from the game development industry how they could leverage GraphQL Federation for their upcoming projects. We came up with a fundamentally new way to think about GraphQL Federation that's leveraging the Open/Closed Principle (OCP) to create a modular, reusable API architecture for development teams working on multiple similar projects.

I call this approach Project-based SuperGraphs with shared base Subgraphs.

The Open Closed Pprinciple originates from the SOLID principles of object-oriented design. It states that a software entity should be open for extension but closed for modification. In the context of API development, we're taking a look at how GraphQL Federation supports this principle, what the benefits are, and how this differentiates from traditional REST APIs.

In software design, the Open/Closed Principle (OCP) is one of the five SOLID principles. It states:

"Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification."

This means you should be able to add new functionality to a system without modifying its existing code. A classic example in Object-Oriented Programming is using polymorphism to extend behavior.

Let's say we have a Shape class, and we want to calculate areas for different shapes. A bad design that violates OCP would look like this:

• Adding a new shape (e.g., Triangle) requires modifying the getArea method, which breaks the closed for modification rule.
• The code becomes harder to maintain over time.

Instead of modifying Shape, we can extend it with new classes:

Now, if we need a Triangle, we simply extend the Shape class without modifying existing code.

In API development, the Open/Closed Principle means we should be able to add new fields and functionalities without modifying existing endpoints. As we'll find out, traditional REST APIs often struggle with this, while GraphQL Federation is designed to support it seamlessly.

Let's look at an example.

A basic REST API serving user data:

Now, we need to add an address field to user data:

• Modifies existing code, risking breaking clients.
• Grows in complexity when new fields (e.g., phoneNumber) are added.
• REST APIs often resort to versioning (/v2/users), which increases maintenance costs.

Unlike REST, GraphQL Federation allows extending APIs dynamically without modifying existing services.

A microservice providing basic user data:

✅ This service remains unchanged when we add new functionality.

A game development company can create a multi-tenant score service that provides the base functionality for "game scores" as a subgraph. Other teams can then use this service as a foundation and extend it for their specific games.

• Base scores subgraph: Provides a standard Score entity with fields like playerId and points.
• Game-specific extensions:
  • A game with a virtual currency can extend the Score entity to include currencyEarned.
  • A shooter game can extend Score to include a killDeathRatio field.

This can be facilitated by having the scores subgraph provide the base entities, which the individual game subgraphs then extend with their additional functionality.

What's amazing about this approach is that the base scores subgraph can be operated independently by the team owning it. Individual game teams can then add this base service to their Supergraph and extend it with game-specific Subgraphs.

• 🚀 GraphQL Federation fully supports the Open/Closed Principle, allowing APIs to evolve without modifying existing services.
• ❌ REST APIs struggle with OCP, requiring constant modifications and versioning.
• ✅ SuperGraph & GraphQL Federation make modular, scalable API development possible.

In summary, this blog post shows that GraphQL Federation can be used in more than just one way. Traditionally, you'd have a single Supergraph that combines all your services into one. However, for project-based development like for example in games, you can create one Supergraph per project, which builds on top of shared base Subgraphs.

With REST APIs, you'd have to modify core services to add new functionality. Either you'd have to deploy a version of the core services for each project, or you have to extend the core services with project-specific versions.