GraphQL Federation: Microservices med ett enhetligt API-lager

Microservices löser ett organisatoriskt problem - team kan arbeta oberoende - men skapar ett nytt för konsumenterna: plötsligt ska en frontend prata med tjugo olika tjänster, var och en med sitt eget API. Det vanliga svaret är en API-gateway, men i GraphQL-världen finns ett mer elegant alternativ: federation, där varje tjänst bidrar med sin del av ett gemensamt schema och konsumenten ser ett enda enhetligt API. Den här djupdykningen förklarar hur det fungerar och, lika viktigt, när ni inte ska göra det.

Att designa API-lagret över ett microservice-landskap är en del av mitt arbete inom systemintegration, och federation är ett kraftfullt verktyg som lätt blir för tidigt valt.

Problemet federation löser

Tidiga försök att samla flera GraphQL-tjänster använde schema stitching, där en gateway manuellt sydde ihop scheman. Det blev skört och svårt att underhålla - gatewayen behövde känna till för mycket om varje tjänst. Federation vänder på det: i stället för att en central punkt vet allt, deklarerar varje tjänst själv vilken del av den gemensamma grafen den äger, och en gateway komponerar ihop delarna automatiskt. Ansvaret hamnar hos teamet som äger datan, inte hos en flaskhals i mitten.

Subgrafer och supergrafen

Grundbegreppen är två. En subgraf är en enskild tjänsts schema - användartjänsten äger typen User, ordertjänsten äger Order. Supergrafen är den sammansatta helheten som gatewayen exponerar mot konsumenterna. Det fina är att en subgraf kan utöka en typ som ägs av en annan: ordertjänsten kan lägga till fältet orders på User utan att användartjänsten behöver veta om det. Frontend frågar efter en användare med dess ordrar i en enda fråga, och gatewayen hämtar bitarna från respektive tjänst och fogar ihop dem.

Gatewayen och kompositionen

Gatewayen, ofta en router, gör två saker. Vid driftsättning komponerar och validerar den subgraferna till en supergraf - och fångar konflikter innan de når produktion, exempelvis om två tjänster definierar samma typ oförenligt. Vid körning tar den emot en fråga, delar upp den i delfrågor mot rätt subgrafer, och sätter ihop svaret. För konsumenten är allt detta osynligt; de ser ett API.

Det här är där det blir svårt

Federation är inte gratis, och jag vill vara rak med kostnaderna. Prestanda kräver omsorg: det klassiska N+1-problemet återkommer i federerad form när gatewayen hämtar relaterad data, och utan eftertanke kan en enda fråga utlösa många anrop mellan tjänster. Felhantering blir mer nyanserad - vad händer med svaret när en subgraf är nere men inte de andra? Auktorisering måste tänkas igenom tvärs över grafen, så att ett fält inte oavsiktligt blir åtkomligt via en omväg. Och observabilitet blir avgörande: när en fråga rör fem tjänster måste ni kunna spåra var den blev långsam. Inget av detta är olösligt, men allt kräver mognad.

När federation inte är värt det

Här är min ärligaste poäng. Federation lönar sig när ni har flera team som äger varsin domän och som behöver utvecklas oberoende - det är ett organisatoriskt verktyg lika mycket som ett tekniskt. Har ni två eller tre tjänster och ett team är federation nästan alltid för tidigt. Då är overheaden - en router att drifta, kompositionsregler att förstå, distribuerad felsökning - större än vinsten, och en enklare lösning räcker gott. Jag har avrått flera bolag från federation just för att de inte hade den teamstruktur som gör den värd besväret. Börja monolitiskt eller med en enkel gateway, och inför federation när organisationen faktiskt har vuxit ikapp. Ett exempel på en sådan bedömning finns i kundcase, och hela vägvalet kan jag göra med er inom systemintegration.

Relaterat

• API-first arkitektur: REST vs GraphQL vs gRPC vs tRPC beslutsguide
• Event-driven arkitektur med Kafka vs RabbitMQ vs AWS EventBridge
• OAuth 2.0 och OIDC i produktion: Säker API-autentisering steg för steg

Vill du ta det vidare?

Jag hjälper svenska bolag att avgöra om GraphQL Federation är rätt nu - och i så fall designa subgrafer, gateway och flöde så att det håller. Boka ett förutsättningslöst samtal.