REST eller GraphQL? Det kedelige svar er ofte det rigtige

Når vi skal vælge API-teknologi til et nyt projekt, starter diskussionen sjældent med GraphQL. Ofte starter den med et langt mere jordnært spørgsmål: Hvem skal bruge API'et, og hvad skal de bruge det til?

REST er stadig vores standardvalg til mange systemintegrationer. Ikke fordi GraphQL er dårligt, men fordi REST er velkendt, nemt at fejlsøge og understøttet af stort set alt fra ERP-systemer til API gateways. Hvis et API forbinder to veldefinerede systemer med relativt stabile databehov, er der sjældent en gevinst ved at gøre det mere avanceret.

Hvornår bliver GraphQL interessant?

GraphQL bliver interessant, når den samme backend skal betjene flere forskellige klienter med forskellige behov. En webapp, en mobilapp og et administrationssystem kan eksempelvis have brug for forskellige udsnit af den samme datamodel. Her kan det være en fordel, at klienten selv kan bede om præcis de felter, den har brug for.

Til gengæld flytter man kompleksitet ind i API-laget. Query-kompleksitet, autorisation, caching og performance kræver mere omtanke. Det er ikke nødvendigvis et problem, men det skal være et bevidst valg.

Et eksempel fra virkeligheden

Forestil jer et ERP-system, der skal sende ordrer til et lager- eller logistiksystem. Dataformatet er kendt, operationerne er tydelige, og integrationen skal være stabil i mange år. Her ville vi næsten altid starte med REST.

Forestil jer i stedet en produktplatform med mange relaterede datatyper og flere frontend-klienter, hvor hver klient løbende får nye behov. Her kan GraphQL være et langt bedre match.

Man behøver ikke vælge én religion

REST og GraphQL kan sagtens leve i samme systemlandskab. En løsning kan eksponere GraphQL til egne frontend-klienter og samtidig integrere med eksterne systemer via REST. Det vigtigste er, at grænsefladen passer til sit ansvar.

Vores tommelfingerregel

Hvis REST løser problemet enkelt og tydeligt, vælger vi REST. Hvis GraphQL fjerner reel kompleksitet for flere klienter, tager vi det med i overvejelserne. Teknologien skal løse et problem, ikke skabe et nyt.