GraphQL är i grunden ett frågespråk för att hämta och ändra data på en server, och för att prenumerera på ändringar. I stället för att göra flera olika API-anrop, som i REST, så ställs en fråga efter alla data som behövs.
Typiskt användning är där en webbläsare först hämtar och fyller i en webbsida med användaranpassad information, sedan sänder tillbaka ändringar utifrån användarens inmatning och sedan fortlöpande mottar rapporterar från servern när relevant information ändrats. Främsta unika egenskap är frågespråket som kan efterfråga hierarkiska data med relationer och få dessa i urval levererade i samma struktur som de efterfrågas.
Vem ligger bakom GraphQL?
GraphQL utvecklades först av Facebook 2012 och publicerades 2015 som open source. Utveckling sker fortlöpande, t ex lades scheman till i januari 2018.
Vad är GraphQL inte?
GraphQL är inte en enskild implementation av eller för klienter eller servrar: Det finns däremot flera implementationer av GraphQL för flera språk och plattformar. GraphQL är inte ett programmeringsspråk: Det innehåller däremot ett frågespråk, ett schemadefinierande språk och ett typdefinierande/datamodellerande språk.
GraphQL vs REST
Då REST är en välkänd arkitektur för webbtjänster är det givande att beskriva GraphQL visavi REST. GraphQL utvecklades av Facebook för att REST var otillräckligt för deras behov. De största skillnaderna har tonvikten på flexibilitet och effektiv resursanvändning. Det är också stor skillnad på var och när den största utvecklingsinsatsen behöver göras. Både REST och GraphQL kan användas i andra tillämpningar än webb, men båda har utvecklats primärt för det ändamålet.
När och för vem är REST bäst?
- När API:t skapas för en känd klient: Klientens behov av data är känt och ett skräddarsytt API effektiviserar utveckling och användning.
- När klienten eller dess utvecklare behöver ett enkelt gränssnitt: Flexibiliteten hos frågespråket behövs inte, utan komplicerar för vissa utvecklare eller typer av klienter.
- När klientens behov av data styrs av en eller få och kända parametrar, t ex datum, sorteringsordning och antal: Domänen och dess data kan vara så enkel till sin natur att få och enkla REST-anrop är optimalt.
- När klientens behov av data inte ändras till sin struktur, t ex att samma sorts objekt hämtas och merparten av dess egenskaper används: Vissa tjänster och data är hård förankrade i standarder eller hävd och har därför låg förändringsgrad.
- När andra datatyper än text behöver hämtas direkt: GraphQL har inte stöd för andra mediatyper än text, t ex bilder, video, ljud, binärdata osv.
När är och för vem är GraphQL bäst?
- När klientens behov av urval av objekt varierar eller är avancerat, t ex urval via relationer mellan objekt: Domänen är komplex till struktur och har potentiellt hög omsättning av data, aktiv utveckling av server- och klientdel kan bromsas av fasta API:er.
- När klienten behöver göra följdfrågor mot servern baserat på en tidigare hämtning: Då data har djup struktur och/eller relationer mellan dessa eller då urvalskriterier är många eller har komplexa villkor.
- När klientens behov av objektens parametrar varierar, t ex då bara få parametrar i stora objekt behövs: Om data behöver samlas ihop från flera typer av objekt måste ett REST-API skräddarsys för detta för att undvika onödig belastning på server och nätverk.
Att kombinera de två
Ett större integrationsprojekt eller en webbtjänst kan förstås passa in på flera av ovanstående beskrivningar, så en kombination av GraphQL och REST kan vara den bästa övergripande API-lösningen.
Att migrera mellan de två
En framgångsrik migrering från REST till GraphQL kräver en del förarbete i studier av statistik från anrop och belastning på befintligt API. Vilka användningsfall sorterar under "När och för vem är XXX bäst?" ovan, t ex? Typiska mål är att få ner antalet anrop och komplexitet i bearbetning på klienten. En effektiv cachningslösning på klienten kan kräva identifiering av återanvändbara objekt och strukturer, och en anpassning till detta i både datamodell och frågor.
En framgångsrik migrering från GraphQL till REST skulle kunna göras ifall en användningsstudie kommer fram till att klientens behov egentligen bara sorterar under "När och för vem är REST bäst?" ovan. Men eftersom en GraphQL-lösning har högsta kostnaden i början på utvecklingen verkar ändå en sådan migrering svårmotiverad.
Publicering av GraphQL-API:er
Att dokumentera GraphQL
Med introduktionen av GraphQL Schema Definition Language (SDL) kan API:et visualiseras och överblickas enklare. Det finns flera verktyg för att grafiskt visualisera dessa, även interaktiva:
graphqlviz
Frågespråket har även stöd för att efterfråga schemat.
Analys och statistik
För insamling och analys av annat än grundläggande information såsom antalet anrop, anropsfrekvens per klient, datamängder överförda, allmän serverbelastning och så vidare krävs att servern som implementerar GraphQL har särskilt stöd för detaljerad analys och statistik, liknande den för databasservrar.
Implementationer för klienter
Apollo Client: En produktionsfärdig GraphQL-klient främst för React, men även för JavaScript, iOS och
Android. MIT Licens.
Relay / Relay Modern: Ett javascriptbibliotek för att bygga React-applikationer baserade på GraphQL. Utvecklat och används av Facebook. Publicerat under MIT License.
React: är ett bibliotek för att bygga användargränssnitt, underliggande Apollo och Relay / Relay Modern.
Implementationer för servrar
GraphQL-bibliotek för serversidan finns för de flesta populära programmeringsspråk, såsom Java, Ruby, Python, Elexir, Scala och JavaScript (i NodeJS). MuleSofts Anypoint Exchange har stöd för GraphQL.
Resurser online
En bra och heltäckande genomgång av GraphQLs många aspekter finns på How To GraphQL.
