Why developers should keep an eye on Fusion

When developing software, it may happen that you need information from another source for your application. For example, you may want to connect to a social network to obtain information about a particular person and simultaneously about their contacts. The choice of a social network in this example is not coincidental, as in 2015, Facebook introduced a solution that can precisely help with this problem: GraphQL.

GraphQL and the rise of microservices

GraphQL is a query language for your APIs and serves as an alternative to REST APIs. The user determines which information to retrieve, thus preventing over-fetching. This means you can accomplish in one request what previously required multiple API calls. Due to its ability to execute multiple queries simultaneously, it is a very efficient solution.

While GraphQL works very well and the open-source community around it remains active, its usefulness has somewhat diminished in recent years, says Sven Quintens, Full Stack Developer at Axxes. "Due to the increasing complexity of codebases in recent years, they have been split into microservices. Each microservice is designed to perform only one specific task, making it easier to scale or maintain with multiple teams. While this is convenient, it poses challenges for querying information. Data becomes more distributed across different servers, making GraphQL less usable."

Enter Fusion

Fortunately, there is a new platform that will make the lives of .NET developers easier: Fusion, a project by ChilliCream that recently launched and allows us to interact with multiple microservices from a single central point. "As a developer, you need to define your microservices initially, so it's clear where everything is located. With that configuration, Fusion can optimize your requests as much as possible and load all microservices to then merge all the information into one cohesive whole," says Sven.

In practical terms, you work in two phases:

1. Build subgraph (package subgraph): These are the microservices.
2. Deployment pipeline: Upload the pipeline to a Redis cache or StrawBerryShake instance.

In the gateway, you load the configurations of the selected cache server, optionally with hot-reload. Fusion will always try to interact with the least possible number of microservices. For example, if one service contains similar data to another service, you can choose to retrieve all the data from this one place.

In conversation with Michael Staib

The significant advantage of Fusion is, of course, the time saved by being able to refer to a single endpoint to selectively retrieve the desired data. At Axxes, we are not currently using it since it has just been launched, but on projects that we can build from scratch, it can be very interesting. Our Full Stack Developer Sven had a conversation with Michael Staib, one of the initiators of the Hot Chocolate project at ChilliCream, who is also closely involved with Fusion, and he had this to say:

“Fusion is a novel approach to managing GraphQL gateways, aiming to provide a more flexible, efficient, and resilient system than traditional gateways, schema stitching, or GraphQL federation. It combines the benefits of both schema stitching and federation while eliminating some of their limitations. The central problem Fusion aims to solve is the complexity and rigidity often associated with managing federated schemas and gateways. With traditional methods, subgraphs (individual services) need to be designed and configured specifically for federation, which can add significant complexity to the system. Fusion, on the other hand, allows subgraphs to be simple GraphQL servers. It can integrate these servers into a cohesive system without any explicit configuration, reducing the management overhead and simplifying the architecture. In addition, Fusion supports data sharding, meaning it can route requests based on user input data to different subgraphs, improving performance and efficiency. A significant advantage of Fusion is its fault tolerance feature. If Fusion detects a malfunctioning or down subgraph, it can automatically recalculate execution plans to reduce the impact on the end user, ensuring the system's reliability and resilience. Lastly, Fusion can serve as a drop-in replacement for Apollo federation, enabling organizations to upgrade their system seamlessly without a complete overhaul. Notably, GraphQL Fusion is an open specification under the MIT license, which means it's freely available for any organization or developer to implement. This open specification fosters collaboration, innovation, and wide adoption, as anyone can contribute to its development or tailor it to their specific needs.

In summary, Fusion stands for a more straightforward, flexible, and resilient approach to managing GraphQL gateways. It brings together the advantages of both schema stitching and GraphQL federation while simplifying system architecture, improving performance, ensuring system resilience, and promoting open collaboration.”

If you want to learn more about Fusion and the evolution of the project, you can join their Slack channel on the ChilliCream website.