Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.
Chilicream Fusion
De laatste jaren zijn microservices steeds populairder geworden. Microservices zorgen ervoor dat je met meerdere teams eenvoudig aan dezelfde applicatie kan werken, dat je een betere afscheiding hebt van de verschillende taken van een applicatie, dat je deze taken individueel kan schalen, en zoveel meer. Deze opsplitsing naar microservices veroorzaakt weer een nieuw probleem in de front-end, een probleem dat GraphQL juist probeerde op te lossen. De front-end moet eerst een call maken naar de ene service vooraleer men de informatie van de andere kan verkrijgen.
Hiervoor heeft Chilicream een nieuw platform op GraphQL ontwikkeld... Fusion. Om deze verschillende services met “zero”-configuratie te fusioneren in één gateway.
Met HotChocolate (C# library voor GraphQL), BananaCakePop (IDE voor het aanmaken, bekijken en testen van GraphQL schemas), StrawberryShake (client om moderne .NET apps te maken) en Barista (.NET command line om GraphQL APIs en schemas te managen) heeft Chilicream al enkele zeer grote producten.
Vanaf eind augustus 2023 komt hier Fusion bij.
Op het einde van dit artikel vind je een quote die verkregen is bij Micheal Staib zelf.
Maar eerst wat is GraphQL?
In 2012 bracht Facebook zijn eerste mobiele versie van de app uit. Deze release was echter geen daverend succes. De app duurde lang om op te starten, was traag en totaal onbruikbaar door de hoeveelheid aan crashes. Dit kwam doordat men eenvoudig de views van hun mobiele website hergebruikte in hun app volgens het “write once, run anywhere”-principe.
Neem het voorbeeld dat je wilt zien wie de vrienden van een gebruiker zijn. Dan zal er eerst een request moeten gemaakt worden voor ‘user/xxx’, gevolgd door een request voor ‘user/xxx/friends’.
Hiervoor bedacht Facebook GraphQL. In GraphQL bepaal je namelijk als ‘gebruiker’ wat er opgevraagd wordt in je request, wat over-fetching tegengaat. Een ander voordeel van graphQL is performance, je kan namelijk meerdere queries tegelijk uitvoeren of in één roundtrip. Zelf met microservices!
Enter... Fusion
Het zal hierbij ook rekening houden met schema types met dezelfde naam en deze dan ook samenvoegen. Al kan je ook vergelijkbare types laten samenvoegen zoals bvb. Author (wat eigenlijk ook een user voorsteld) en User.
Hoeveel configuratie betekent “zero”-configuratie? Je kan het meeste van dit allemaal laten gebeuren door jouw (azure) pipelines.
Het te doorlopen proces is:
- Build subgraph (package subgraph) => dit zijn de microservices
- 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 en dan ben je al klaar.
Natuurlijk is er additionele configuratie mogelijk. Zoals in het voorbeeld met de Author en User, kan je configureren dat de Author ook van het User type moet zijn.
Fusion zal ook steeds proberen om het minst mogelijk aantal microservices aan te spreken. Wanneer vergelijkbare data gevonden kan worden op één service, waar hij reeds andere data moet ophalen, dan zal er altijd gekozen worden om alle data van deze service te halen.
Mocht je meer interesse hebben twijfel zeker niet om Sven Quintens aan te spreken of de ondertstaaned video “Getting started met Fusion” te bekijken .
Tenslotte kan je de HotCholate Slack joinen en op de hoogte blijven van de komende updates door het “fusion” kanaal te joinen. Zo komt binnenkort nog de ondersteuning van OpenTelemetry logging, wat reeds ondersteund is in HotChocolate GraphQL servers zelf.
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.
