Grunnleggende om Schema Stitching

Se for Dem at De har flere GraphQL-tjenester, kanskje fra ulike team eller til og med basert på ulike backend-teknologier. Hvordan presenterer De dem som ett samlet API for frontend-løsningen? Det er her Schema Stitching kommer inn!

Det lar Dem kombinere flere uavhengige GraphQL-skjemaer til ett samlet gateway-skjema.

I store applikasjoner kan ett enkelt, omfattende API (en «monolitt») bli vanskelig å administrere. Ulike team kan komme i veien for hverandre, og utrullinger blir risikable.

• Langsom utvikling: Endringer påvirker hele systemet.
• Utrullingsrisiko: En feil i én del kan føre til at alt slutter å fungere.
• Skaleringsproblemer: Det er vanskelig å skalere bestemte deler uavhengig av hverandre.

Mikrotjenester deler opp en applikasjon i mindre, uavhengige tjenester. Hver tjeneste kan ha egne data og et eget API.

Når hver mikrotjeneste eksponerer sitt eget GraphQL-skjema, må klientene kjenne til og spørre mot flere endepunkter. Dette gjør frontend-løsningen mer kompleks.

De har kanskje også hørt om GraphQL Federation. Selv om begge teknologiene samler API-er, gjør de det på ulike måter.

• Stitching: Kombinerer eksisterende skjemaer og er ofte ideelt for integrering av eldre eller tredjeparts-API-er.
• Federation: Er laget for å bygge nye mikrotjenester fra grunnen av, der hver tjeneste bidrar med deler av én samlet graf.

Denne leksjonen fokuserer på Schema Stitching.

Tenk på en «stitching-gateway» eller «API-gateway». Denne gatewayen fungerer som ett enkelt inngangspunkt for klienter.

Den henter skjemaer fra individuelle backend-tjenester (kalt «delskjemaer») og kombinerer dem deretter til ett «samlet skjema» som klientene samhandler med. Gatewayen videresender så spørringene til riktig delskjema.

La oss si at vi har to tjenester:

• Brukertjeneste: Administrerer brukerprofiler.
• Produkttjeneste: Administrerer produktoppføringer.

Hver tjeneste eksponerer sitt eget GraphQL-skjema:

# User Service Schema
type Query {
  user(id: ID!): User
}
type User {
  id: ID!
  name: String
  email: String
}

# Product Service Schema
type Query {
  product(id: ID!): Product
}
type Product {
  id: ID!
  name: String
  price: Float
}

Stitching-gatewayen slår sammen rot-typene Query og Mutation fra alle delskjemaene til én enkelt rot-type Query og Mutation i det samlede skjemaet.

Dermed kan en klient spørre etter user(id: "1") OG product(id: "101") fra det samme endepunktet.

Hva om en User trenger å kjenne til Product-bestillingene sine? Schema Stitching lar Dem utvide typer. Produkttjenesten kan for eksempel utvide User-typen med et orders-felt.

Gatewayen håndterer dette ved først å spørre brukertjenesten etter brukeren og deretter bruke brukerens ID til å spørre produkttjenesten etter bestillingene.

Schema Stitching har flere fordeler:

• Samlet API: Ett endepunkt for alle tjenestene.
• Modularitet: Team kan bygge og rulle ut tjenester uavhengig av hverandre.
• Fleksibilitet: Det er enkelt å integrere tredjeparts-API-er eller eldre systemer.
• Enklere frontend: Klientene trenger ikke å kjenne til grensene mellom backend-tjenestene.

I denne leksjonen utforsket vi Schema Stitching, en effektiv teknikk for å kombinere flere GraphQL-API-er til én samlet API-gateway. Vi så hvordan dette gjør det enklere å administrere mikrotjenester og forenkler klientopplevelsen ved å tilby ett endepunkt for ulike datakilder.

Deretter skal vi se nærmere på den praktiske implementeringen av sammenslåing av flere GraphQL-skjemaer i et Spring Boot-miljø.