Teknologikjemper omfavner GraphQL

Det er kun få år siden API-spørrespråket GraphQL ble offentliggjort etter å ha vært brukt og utviklet internt hos Facebook siden 2012.

Ikke desto mindre har språket funnet vei til en rekke store IT-selskaper, som Netflix, Paypal og Airbnb.

Ett av de store trekkplastrene til språket er hastighet. I GraphQL kan brukere spesifisere de felter hun eller han er interessert i, og definere hvordan data skal struktureres. Resterende datafelter kan ignoreres, noe som gir raskere svartider og mindre press på serveren.

Det har vært viktig hos Netflix, som i selskapets markedsavdeling har bygget GraphQL inn i et lag mellom klienten og et REST-API.

«Since GraphQL allows the client to select only the data it needs we end up fetching a significantly smaller payload», skriver de to utviklerne Artem Shtatnov og Ravi Srinivas Ranganathan i et blogginnlegg om erfaringer ved overgangen til GraphQL.

«In our application, pages that were fetching 10MB of data before now receive about 200KB. Page loads became much faster, especially over data-constrained mobile networks, and our app uses much less memory.»

Flere spørringer blir én

Hos Paypal gikk man for fire år siden «all in» på REST-API-er, men det har gitt selskapet utfordringer med hastigheten.

«If your applications are consuming atomic REST APIs, you’re often making many round trips from the client to the server to fetch data», forteller PayPals Principal Engineer Mark Stuart i et blogginnlegg.

Hvis du for eksempel vil ha en liste over bøker som en bestemt forfatter har skrevet, på bakgrunn av en enkelt boktittel, skal du potensielt først be et API om forfatteren til bok X, og deretter lage en spørring (query) til et annet API, hvor du bruker forfatteren som input for å få en liste over dennes bøker.

«We’ve found that every round trip costs at least 700ms in network time (at the 99th percentile), not counting the time processing the request on the server. Every round trip results in slower rendering time, more user frustration and lower Checkout conversion. Needless to say, round trips are evil!», fortsetter han.

Med en enkel GraphQL-spørring kunne du i stedet starte med boktittelen og i samme spørring bedt om bokens forfatter og en liste over dennes bøker. Altså én «request» i stedet for flere.

Dette kan la seg gjøre fordi brukeren med GraphQL mapper relasjoner mellom data – som boktittel og forfatter – i en graf med et såkalt skjema, en datadefinisjon. Dette skal kun gjøres én gang.

«When the consumer application fetches data from multiple sources, it no longer needs to worry about the complex business logic associated with data join operations», skriver Netflix-utviklerne.

• GraphQL er en av tre Javascript-teknologier du bør se på »

En «game changer»

Alternativet til de onde «round trips» er å bygge API-ene så de returnerer mye mer data. Men den strategien har hos Paypal gjort at API-ene har blitt tunge og klossete over tid.

«We started with great intentions. Our API returned user information, a shipping address and funding options. Everything you need to build a Checkout app. Over time, use cases pile up. Every user pays the cost of these fields even if they don’t need them.»

Paypals utviklere brukte en uke på å undersøke mulighetene for å unngå «overfetching» av data med GrapQL. Etter å ha prøvd ut språket i et seks uker langt utviklingsprosjekt, vurderte selskapet at GraphQL både løser problemer med ytelse og med vanskelig adgang til data for utviklere.

«At PayPal, GraphQL has been a complete game changer to the way we think about data, fetch data and build applications», skriver Mark Stuart.

• Norske utviklere satser på GraphQL: eZ-brødrene i ferd med å ta nytt programvarehus ut i verden. De lokker også verdens utviklere til Skien

Kan skjule kompleksitet på godt og ondt

Som med alle digitale verktøy er det ulemper også ved bruken av GraphQL, og situasjoner hvor REST-API-er er å foretrekke.

Hos Netflix noterer man seg blant annet at det abstraksjonslag som GrapQL leverer gjør utviklere mer effektive, men kun inntil noe slutter å virke.

«There will undoubtedly be bugs in our code and we didn’t want to obfuscate the root cause with a middle layer. GraphQL would orchestrate network calls to other services automatically, hiding the complexities from the user», skriver utviklerne.

Logrocket-utvikler Estaban Herrera skriver i en gjennomgang at GraphQL kan gjøre enkle oppgaver mer komplisert, blant annet fordi REST-API-er gjør det lettere å håndtere feilmeldinger.

GraphQLs styrke kan også bli en kjepp i hjulet når det gjelder ytelse hvis du ikke er forsiktig, påpeker Herrera.

«A GraphQL API must be carefully designed, it’s not just about putting it on top of a REST API or a database.»

Artikkelen har tidligere vært publisert på Datatech. Datatech tilhører Teknologiens Mediehus.