Software Architectuur
Het Dilemma van de Enkele GraphQL Server
Toen GraphQL werd geïntroduceerd als de superieure opvolger van REST API’s, beloofde het een prachtig utopia voor frontend-developers: één enkel, uniform eindpunt (endpoint) waarmee ze alle benodigde data over de hele organisatie heen konden opvragen via één krachtige query. Echter, naarmate de adoptie groeide binnen enterprise-organisaties met microservices-architecturen, stuitte men op een organisatorisch en technisch schaalprobleem. Om dat ene magische GraphQL eindpunt te realiseren, moest de gehele bedrijfsstructuur (het schema) in één monolithische GraphQL-server of API Gateway worden gepropt. Dit leidde ertoe dat tientallen ontwikkelteams (bijv. het voorraad-team, het gebruikers-team en het facturatie-team) allemaal in dezelfde codebase moesten werken om hun resolvers en types te updaten, met eindeloze merge-conflicten en releases-bottlenecks als gevolg.
De oplossing voor deze architectonische knoop is GraphQL Federation, grootgemaakt door het Apollo Supergraph (Apollo Federation) ecosysteem.
Decentraal Ontwikkelen, Centraal Bevragen (Subgraphs)
Met GraphQL Federation wordt de monolithische API opgebroken in kleine, hanteerbare stukjes genaamd ‘Subgraphs’. Elk ontwikkelteam beheert zijn eigen Subgraph (als een opzichzelfstaande GraphQL microservice). Het e-commerce team bouwt en beheert de Product subgraph. Het logistieke team bouwt de Voorraad subgraph. Elk team kan zijn subgraph deployen onafhankelijk van de andere teams, in hun eigen programmeertaal (de één in Node.js, de ander in Go of Java).
De magie zit in het middelpunt: de Apollo Router (of Gateway). De Router kent de schema’s van alle individuele subgraphs en weeft deze dynamisch samen tot één gigantische ‘Supergraph’. Als de frontend ontwikkelaar een query stuurt naar de Router, bijvoorbeeld: “Geef mij product X, inclusief de beschrijving (uit de Product subgraph), de actuele voorraad (uit de Logistiek subgraph) en de laatste reviews (uit de Review subgraph)”, ontvangt de Router deze query. De Router ontleedt de vraag, stuurt parallel razendsnelle requests naar de drie afzonderlijke subgraphs, voegt de geretourneerde data netjes samen in één JSON-object, en stuurt het terug naar de frontend. De frontend weet absoluut niet dat de data uit drie verschillende microservices komt.
Entiteiten Koppelen over Grenzen Heen
Wat Federation krachtig maakt, is de mogelijkheid om entiteiten (zoals een User) over grenzen heen uit te breiden. Het Account-team definieert het basis User type (met id en naam). Het Review-team kan in hún subgraph datzelfde User type uitbreiden met een veld laatsteReviews. De teams hoeven elkaars code niet te kennen; door het gebruik van directives zoals @key en @extend in hun GraphQL-schema, snapt de Router automatisch hoe deze velden op basis van het User ID gekoppeld moeten worden.
Schema Registry en Observability
Omdat tientallen subgraphs het schema kunnen aanpassen, is governance cruciaal. Apollo biedt een centraal Schema Registry. Wanneer een team een update doet (bijv. ze verwijderen een veld uit hun subgraph), analyseert de registry direct (tijdens de CI/CD pipeline) of deze verwijdering actieve query’s van frontend-applicaties zal breken (Schema Checks). Als dit het geval is, wordt de deployment geblokkeerd. Dit voorkomt downtime. GraphQL Federation is dé standaard geworden voor grote ondernemingen (zoals Netflix, Booking.com en Walmart) om de wendbaarheid van microservices te combineren met het gemak van één uniforme data-API. Voor een breder perspectief op microservices, lees AG Connect.
Volgende: Docker vs. Podman: De Transitie naar Daemonless en Rootless Containers
