Tech-kæmper omfavner GraphQL: Det har ændret, hvordan vi tænker data

11. februar 2019 kl. 05:121
Tech-kæmper omfavner GraphQL: Det har ændret, hvordan vi tænker data
Illustration: PayPal.
Netflix, PayPal og Airbnb har adopteret GraphQL, bl.a. fordi det er et hurtigt sprog.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Det er kun få år siden API-query-sproget GraphQL blev offentliggjort efter at have være brugt og udviklet internt hos Facebook siden 2012.

Ikke desto mindre har sproget fundet vej til en række store it-selskaber, som Netflix, PayPal og Airbnb.

En af de store trækplastre til sproget er hastighed. I GraphQL kan brugeren specificere de felter, hun er interesseret i, og definere, hvordan data skal struktureres. Resterende datafelter kan ignoreres, hvilket giver hurtigere svartider og mindre pres på serveren.

DataTech

Artiklen her er fra DataTech, et nyt PRO-medie fra Ingeniøren om data og analytics. Vi giver dig inspirerende cases, nyheder og debat om alt fra machine learning­-modeller til dataetik.
Følg med på pro.ing.dk/datatech


Det har været vigtigt hos Netflix, der i selskabets marketingafdeling har bygget GraphQL ind som et lag mellem klienten og 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 udviklere Artem Shtatnov and Ravi Srinivas Ranganathan i en blog 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 queries bliver til en

Hos PayPal gik man for fire år siden all in på REST API'er, men det har givet selskabet udfordringer på hastigheden.

Artiklen fortsætter efter annoncen

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

Hvis du f.eks. vil have en liste af bøger, som en forfatter har skrevet, på baggrund af en enkelt bogtitel, skal du potentielt først bede et API om forfatteren til bog X, og efterfølgende lave en query til et andet API, hvor du bruger forfatteren som input til at få en liste over dennes bøger.

»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!« fortsætter han.

Med en simpel GraphQL-query kunne du i stedet starte med bogtitlen og i samme query bede om bogens forfatter og en liste over dennes bøger. Altså én request i stedet for flere.

Artiklen fortsætter efter annoncen

Dette kan lade sig gøre fordi brugeren med GraphQL mapper relationer mellem data - som bogtitel og forfatter - i en graf med et såkaldt schema, en datadefinition. Dette skal kun gøres en 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-udviklerne.

Game changer

Alternativet til de 'onde' round trips, er at bygge API'erne til at returnere meget mere data. Men den strategi har hos PayPal gjort, at API'erne er blevet tunge og klodsede 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 udviklere brugte en uge på at undersøge mulighederne for at undgå 'overfetching' af data med GraphQL. Efter at have afprøvet sproget i et seks uger langt udviklingsprojektet, vurderede selskabet, at GraphQL både løser problemer med performance og med besværlig adgang til data for udviklere.

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

Kan skjule kompleksitet på godt og ondt

Som med alle digitale værktøjer er der bagsider ved brugen af GraphQL og situationer, hvor REST API'er er at foretrække.

Hos Netflix noterer man sig blandt andet, at det abstraktionslag, som GraphQL leverer, gør udviklere mere effektive, men kun indtil noget holder op med at virke.

Artiklen fortsætter efter annoncen

»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 udviklerne .

LogRocket-udvikler Estaban Herrera skriver i en gennemgang, at GraphQL kan gøre simple opgaver mere komplicerede - blandt andet fordi REST API gør det lettere at håndtere fejlmeddelelser.

GraphQL's styrke kan også blive en kæp i hjulet på din performance, hvis du ikke er forsigtig, bemærker Herrera. Med GraphQL kan en klient potentielt sende request på meget store datamængder og dermed sende en server i knæ.

»For complex queries, a REST API might be easier to design because you can have multiple endpoints for specific needs, and for each, you can fine-tune specific queries to retrieve the data in an efficient way,« påpeger Estaban Herrera.

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

1 kommentar.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
11. februar 2019 kl. 14:17

Og søreme om ikke den nyeste version (5.5) af mainframe transaktionsbehandleren CICS også kan afvikle GraphQL!