Waarom developers Fusion in de gaten moeten houden

Wanneer je software ontwikkelt, kan het gebeuren dat je informatie uit een andere bron nodig hebt voor jouw applicatie. Je wil bijvoorbeeld verbinding maken met een sociaal netwerk om daar informatie te verkrijgen over een bepaald persoon én tegelijkertijd ook van diens contactpersonen. Dat dit voorbeeld over een sociaal netwerk gaat is niet toevallig, want in 2015 kwam Facebook met een oplossing die exact kan helpen bij dit probleem: GraphQL.

GraphQL en de opkomst van microservices

GraphQL is een query taal voor je API's en vormt een alternatief voor REST API's. De gebruiker bepaalt zelf welke informatie je opvraagt, wat over-fetching tegengaat. Zo kan je in één request doen waar je vroeger meerdere API calls voor nodig had. Doordat je meerdere queries tegelijk kunt uitvoeren is het een zeer performante oplossing.

Dat werkt zeer goed, en de open source community rond GraphQL is nog steeds actief, maar toch is het nut ervan de laatste jaren wat verdwenen, zegt Sven Quintens, Full Stack Developer bij Axxes ‘Doordat codebases de voorbije jaren steeds complexer werden, is men ze gaan opsplitsen in microservices. Die moeten maar één specifieke taak uitvoeren, zodat je ze makkelijker kan schalen of met meerdere teams kunt onderhouden. Dat is handig, maar niet voor wie informatie moet opvragen. Alle informatie wordt terug meer verspreid over verschillende servers, waardoor GraphQL minder bruikbaar wordt.’

Enter Fusion

Gelukkig is er een nieuw platform dat het leven van .NET developers makkelijker zal maken: Fusion, een project van ChilliCream dat onlangs lanceerde en ons toelaat om vanuit één centraal punt verschillende microservices aan te spreken. ‘Als developer moet je in het begin je microservices definiëren, zodat duidelijk is wat waar staat. Door die configuratie kan Fusion je request zo goed mogelijk optimaliseren en alle microservices inladen om vervolgens alle informatie samen te voegen tot één geheel’, zegt Sven.

Concreet werk je in twee fasen:

1. Build subgraph (package subgraph) => dit zijn de microservices

2. Deployment pipeline => upload de pipeline naar een Redis cache of StrawBerryShake instantie.

In de gateway laad je dan, al dan niet met hot-reload, de configuraties van de gekozen cache server. Fusion zal steeds proberen om het minst mogelijke aantal microservices aan te spreken. Wanneer op één service bijvoorbeeld vergelijkbare data staat die ook op een andere service staat, kan je ervoor kiezen om alle data van deze ene plek te halen.

In gesprek met Michael Staib

Het grote voordeel van Fusion is uiteraard de tijdwinst, doordat je naar één endpoint kan verwijzen om daar zelf te kiezen welke data je wil ophalen. Binnen Axxes maken we er momenteel nog geen gebruik van aangezien het nog maar net lanceerde, maar op projecten die we vanaf nul kunnen opbouwen kan het zeer interessant zijn. Onze Full Stack Developer Sven had een gesprek met Michael Staib, een van de initiatiefnemers van het Hot Chocolate project van ChilliCream die ook nauw betrokken is bij Fusion, en die wist hem dit te vertellen:

‘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.’

Wil je meer weten over Fusion en de evolutie van het project? Op de website van ChilliCream kan je lid worden van hun Slack-kanaal.