GraphQL er for mange vejen til hastighed og brugervenlighed

Nogle af verdens største firmaer har brugt det i årevis og mange programmører kender GRAPHQL som verdens hurtigste når man gerne vil have samlet mange datakilder.

Nogle af de største firmaer er f.eks. Facebook, Netflix, Wallmart, NYT.COM, Github, PayPal, Shopify og Airbnb har adopteret GraphQL. Dette er ofte fordi det er hastigheden der lokker.

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, og som efterfølgende er udgivet som Open Source.

I GraphQL er det kun de data man skal bruge og ikke resten af data der skal bruges, dermed defineres en skals kanaler hvor data kan struktureres som man vil. Denne enkle egenskab er i sig selv ikke ny, men brugervenligheden og især hastigheden er den afgørende faktor, man spørger i lighed med NoSQL på felter og resten af databasen kan udelukkes.

Vi ved jo af erfaring at vore websider skal være hurtige og med store datamængder kan vi opnå kortest mulige svartider. Netflix, har f.eks. bygget GraphQL ind som et lag mellem klienten og REST API. Som Artem Shtatnov and Ravi Srinivas Ranganathan udtrykker det på sin blog: »Since GraphQL allows the client to select only the data it needs we end up fetching a significantly smaller payload,« — »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.«

Multi Stream Queries

Hos en af verdens største banker PayPal gik man for fire år siden all in på REST API’er, men det har også givet selskabet udfordringer på hastigheden. Som PayPals Principal Engineer Mark Stuart i en blog siger det: »If your applications are consuming atomic REST APIs, you’re often making many round trips from the client to the server to fetch data«

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!« oplyser han. Regner man så på milliarder af strenge med komplekse søgninger bliver det nærmest en nødvendig at følge nye teknikker, for at undgå dårlige brugeroplevelser.

Med en ganske standard GraphQL forespørgsel kan man i stedet starte med bogtitlen og tillige i samme query bede om bogens forfatter og en liste over dennes bøger. Altså én request i stedet for flere. På store bigdata sites, er det ligefrem nødvendigt med denne streaming eller strømligning af søgeresultater for at kunne yde en god kundeoplevelse. Disse Schema eller datadefinitioner eller datarelationer skal kun køres en gang for at være tilgængelige og gør det muligt at få data fra flere kilder, uden at tænke over den komplekse verden der hidtil har hersket når man skulle bruge data mange steder fra. Så det er afgjort at vi ser mere til GraphQL i de danske højtrafik websteder som f.eks. DR.DK der kunne trænge til en ny søgefunktion, der virker bedre end nu.

Mark Stuart fra Paypal skriver det således: »At PayPal, GraphQL has been a complete game changer to the way we think about data, fetch data and build applications,« skriver

Er REST API en dinosaur når man sammenligner med GraphQL

• GraphQL ligner en vinder på brugervenlighed og hastighed, men der er da stadig nogle situationer, hvor REST API’er kan anvendes. Spørgsmålet er bare om tiden ikke er ved at løbe ud, for de værktøjer der ikke selv kan streame og kombinere forespørgsler.
• Dog er der nogle begrænsninger også og det betyder at man formentligt skal tænke sig 2 gange om hvis brugen henhører under SSO logins og dataregler er oprettede i forhold til den kilde der spørger. Autoriseringer kan være et problem i sig selv, vi bruger f.eks. OKTA og AUTH0 og ONELOGIN i nogle APPS.
• Der kan også være begrænsninger hvis den API som anvendes har en såkaldt API RATE BEGRÆNSNING, det er jo ikke unormalt i den sammenhæng.
• Man kan ikke nemt bruge fil-upload sammen med en forespørgsel og det er ikke med i specifikationerne, men man kan bruge et bibliotek til dette, f.eks. Apollo-Upload-Server.
• Endeligt skal man definere hvordan Caching anvendes og til hvilken fordel. Det kan være vanskelige for nogle cache systemer at håndterer GRAPHQL.

Du kan se mere om GraphQL på:

1. Facebook: GraphQL: A data query language – Link
2. The GitHub GraphQL API – Link
3. 3 Reasons Why Astronomer is Betting on GraphQL – Link
4. Shopify: GraphQL and its benefits – Link
5. Implementing GraphQL at Major League Soccer – Link
6. Artsy: Improving Page Speeds with GraphQL – Link
7. Coursera’s journey to GraphQL – Link
8. GraphQL: A success story for PayPal Checkout – Link
9. Walmart Labs: Open Sourcing Lacinia, our GraphQL Library for Clojure – Link
10. Why Companies are Adopting GraphQL – Link