Introduksjon til Apollo Federation

Velkommen til Apollo Federation! Denne kraftige arkitekturen hjelper deg med å bygge ett samlet GraphQL-API fra flere uavhengige mikrotjenester.

Se for deg at du har mange små tjenester, der hver tjeneste har ansvar for en del av applikasjonen. Federation lar dem alle bidra til ett stort GraphQL-skjema.

I en mikrotjenestearkitektur har ulike team ofte ansvar for separate backend-tjenester. Hvordan eksponerer du et sammenhengende GraphQL-API?

• Monolittisk GraphQL: Én stor server som er vanskelig å skalere for store team.
• Flere GraphQL-endepunkter: Klientene må spørre ulike tjenester, noe som øker kompleksiteten.

Federation tilbyr en ryddig løsning på denne utfordringen.

Kjerneideen i Federation er at ulike tjenester (kalt subgrafer) hver kan definere en del av det overordnede GraphQL-skjemaet.

Disse delene kombineres deretter av en sentral Gateway til én samlet graf. Det er som å ha mange bidragsytere til én felles tegning.

Apollo Federation består av to hovedkomponenter i arkitekturen:

• Gateway: Dette er inngangspunktet for alle klientforespørsler. Den kjenner til alle subgrafene og hvordan spørringer skal rutes.
• Subgrafer: Dette er de individuelle mikrotjenestene dine. Hver subgraf implementerer en bestemt del av GraphQL-skjemaet og finner data for sitt domene.

Når en klient sender en GraphQL-spørring til Gateway, skjer følgende i forenklet form:

1. Gateway mottar spørringen.
2. Den analyserer hvilke subgrafer som trengs for å oppfylle forespørselen.
3. Gateway deler opp spørringen og sender bestemte deler til de relevante subgrafene.
4. Deretter kombinerer den resultatene fra alle subgrafene til ett svar til klienten.

Federation gir betydelige fordeler for store systemer i stadig utvikling:

• Skalerbarhet: Team kan utvikle og distribuere subgrafer uavhengig av hverandre.
• Frikobling: Tjenestene forblir autonome, noe som reduserer avhengighetene mellom dem.
• Samlet API: Klientene får ett enkelt og konsekvent GraphQL-endepunkt.
• Sterk typesikkerhet: Hele grafen er sterkt typet, også på tvers av tjenester.

Du har kanskje hørt om Schema Stitching, en annen måte å kombinere GraphQL-API-er på. Hvordan skiller Federation seg fra dette?

Med Stitching kombineres individuelle skjemaer på Gateway, men underskjemaene er ofte ikke klar over hverandre. Det ligner mer på å sette sammen separate dokumenter.

Federation fremmer en virkelig distribuert graf der subgrafene samarbeider eksplisitt og utvider delte typer.

Utførelsesmodellen er en annen viktig forskjell:

• Stitching: Gateway kan hente data fra én tjeneste, deretter en annen, og kombinere dem manuelt. Dette kan føre til mindre optimal datahenting.
• Federation: Gateway forstår forholdene mellom typer på tvers av subgrafer. Den kan planlegge effektive spørringer intelligent og bare hente det som trengs fra hver tjeneste.

Federation egner seg spesielt godt for:

• Store organisasjoner med mange utviklingsteam.
• Komplekse mikrotjenestearkitekturer som trenger et samlet API.
• Situasjoner der du over tid ønsker å eksponere én GraphQL-graf i utvikling.

Hvis du har en mindre og enklere applikasjon, kan én enkelt GraphQL-server være tilstrekkelig.

Når du bygger fødererte subgrafer med Spring Boot, definerer du GraphQL-typene som vanlig. Du bruker imidlertid også bestemte Federation-direktiver.

Det viktigste er @key, som identifiserer primærnøkkelen til en entitet på tvers av ulike subgrafer. Dette gjør det mulig for Gateway å forstå og løse relasjoner.

Godt jobbet! I denne leksjonen introduserte vi Apollo Federation, en kraftig metode for å bygge ett samlet GraphQL-API fra flere mikrotjenester.

• Vi gikk gjennom rollene til Gateway og Subgraphs.
• Vi utforsket hvordan Federation muliggjør et distribuert skjema og effektiv utførelse av spørringer.
• Vi så også hvordan dette skiller seg fra Schema Stitching.

Deretter skal vi se nærmere på hvordan du bygger dine første fødererte subgrafer med Spring Boot!