Migrera från REST till GraphQL: Steg-för-steg utan driftstopp

De flesta som vill migrera från REST till GraphQL gör det av en bra anledning: frontend overfetchar eller underfetchar, varje ny vy kräver en ny endpoint, och klientmångfalden har blivit ett verkligt problem. Den dåliga nyheten är att den vanligaste migreringsplanen - ett stort omskrivningsprojekt som ersätter allt på en gång - nästan alltid spårar ur. Den goda nyheten är att en gradvis migrering, där REST och GraphQL lever sida vid sida, fungerar utmärkt och utan driftstopp. Det är den vägen jag beskriver här.

Innan jag går in på stegen vill jag säga det ärligt: alla ska inte migrera. Den här typen av vägval och genomförande gör jag inom systemintegration, och ibland är slutsatsen att stanna kvar på REST.

Steg 0: Avgör om ni ens ska göra det

Migrera inte till GraphQL för att det är modernt. GraphQL löser ett specifikt problem - många olika klienter som behöver olika dataformer - och flyttar samtidigt komplexitet till cachning, frågekostnad och auktorisering. Har ni ett stabilt REST-API med en handfull konsumenter och inga av smärtorna ovan, är ärliga svaret att låta bli. Den bästa migreringen är ibland den ni inte gör. Är problemen däremot reella och återkommande, fortsätt.

Steg 1: Lägg GraphQL framför befintlig REST

Det första steget kräver inga ändringar i era underliggande tjänster. Ni reser ett GraphQL-lager som internt anropar era befintliga REST-endpoints och översätter svaren. GraphQL blir alltså till en början bara en ny fasad framför det som redan finns. Det låter er börja erbjuda en GraphQL-yta för nya behov utan att röra den fungerande kärnan - och utan risk för det som redan är i drift.

Steg 2: Låt dem samexistera

Det här är hela poängen med att slippa driftstopp. REST-API:et fortsätter att tjäna sina befintliga konsumenter precis som förut, medan GraphQL växer parallellt. Ingen befintlig integration tvingas byta över en natt. Nya vyer och nya klienter byggs mot GraphQL; gamla får ligga kvar tills det finns skäl att flytta dem. Två API-lager som lever ihop är inte en skuld att skämmas över under en migrering - det är själva mekanismen som gör den säker.

Steg 3: Flytta konsumenterna en i taget

När GraphQL-lagret är moget börjar ni migrera klienterna stegvis, inte alla på en gång. Ta en vy, en app eller en konsument i taget, flytta den till GraphQL, verifiera i produktion att den beter sig rätt, och gå vidare. Mät utfallet vid varje steg - svarstider, fel, faktisk användning - så att ni upptäcker problem på en avgränsad yta i stället för i en stor smäll. Varje flyttad konsument är ett steg som går att försvara på egna meriter och att rulla tillbaka om något ser fel ut.

Steg 4: Optimera bort mellanlagret

Så länge GraphQL bara anropar REST under huven har ni ett extra hopp och ärver REST:ets begränsningar - inklusive N+1-problem om resolvers anropar endpoints naivt. När en domän väl trafikeras tungt via GraphQL lönar det sig att låta resolvern prata direkt med datakällan i stället för via REST-endpointen, och att införa dataloaders som batchar anrop. Det här är optimering ni gör där det betalar sig, inte överallt på en gång.

Steg 5: Avveckla det som tjänat ut

När en REST-endpoint inte längre har några konsumenter kan den pensioneras - men först då, och med framförhållning. Kommunicera utfasningen, ge externa parter tid, och behåll gärna REST för rena maskin-till-maskin-fall där det fungerar bra. Målet är inte att utrota REST på principiella grunder, utan att GraphQL ska bära det som faktiskt drar nytta av det. Ett exempel på en sådan stegvis migrering finns i kundcase, och hela genomförandet kan jag leda tillsammans med er inom systemintegration.

Relaterat

Vill du ta det vidare?

Jag leder REST-till-GraphQL-migreringar för svenska bolag - gradvis, mätt och utan driftstopp, och med ärligheten att säga ifrån om ni inte borde migrera alls. Boka ett förutsättningslöst samtal.

Vanliga frågor

Måste vi skriva om allt på en gång för att byta till GraphQL?

Nej, och det bör ni inte. En big bang-omskrivning spårar nästan alltid ur. Lägg i stället GraphQL som ett lager framför befintlig REST, låt dem samexistera och flytta konsumenterna stegvis. Då sker migreringen utan driftstopp.

Hur undviker vi driftstopp under migreringen?

Genom att låta REST fortsätta tjäna sina befintliga konsumenter medan GraphQL växer parallellt. Nya vyer byggs mot GraphQL, gamla flyttas en i taget med mätning och möjlighet att rulla tillbaka. Inget byts över en natt.

Bör alla migrera från REST till GraphQL?

Nej. GraphQL lönar sig när ni har många olika klienter som behöver olika dataformer. Har ni ett stabilt REST-API med få konsumenter och inga av de smärtorna är det ärliga rådet att stanna kvar - den bästa migreringen är ibland den ni inte gör.