English

Polski

Français

Deutsch

日本

Español

Nederlands

RESSOURCER

Hvad er GraphQL?

GraphQL er en måde at kommunikere med API'er på, der er skabt som et alternativ til REST.

01Et nyt forespørgselssprog

GraphQL er et forespørgselssprog til API'er, der blev udviklet af Facebook og deres udviklerfællesskab. Det havde premiere i juni 2018 og er nu en moden teknologi, der har opnået stor anerkendelse på markedet. Som følge heraf er det velkendt, og mange virksomheder vælger at implementere det. For t-o fortælle dig, hvordan den er anderledes, er vi nødt til at se på det, der stadig er mest udbredt: REST, og hvad den er baseret på. GraphQL kaldes ofte for REST's efterfølger, fordi det løser dets centrale problemer. Som du sikkert ved, er det baseret på en slags gammelt systemdesign. Ifølge det er hver datamodel tilgængelig på en separat adresse. Har vi f.eks. en onlineshop med tøj, kan vi have adresser til indkøbskurv, lager, produkter og mange flere.

GraphQL forespørgselssprog

02Få kun det, du ønskede

Faktisk vil antallet af sådanne adresser aldrig være lille, tværtimod vil det vokse med systemet. Husk på, at du for næsten hver adresse skal oprette et sæt kald til håndtering af get-, post-, put- eller sletteanmodninger. Dette vil resultere i et stort antal adresser, der skal vedligeholdes, og et endnu større antal kald, der er nødvendige for at hente dataene. GraphQL fungerer på en helt anden måde. Vi har kun én adresse, en enkelt sandhedskilde, hvorfra vi kan anmode om data. Hvad vi får, afhænger udelukkende af os, og hvordan vi konstruerer forespørgslen.

GraphQL-forespørgsel

03Fleksible forespørgsler

Den vigtigste funktion i GraphQL er muligheden for at udføre fleksible forespørgsler, hvor vi definerer præcis hvilke data fra API'et vi ønsker at hente. Derudover giver sproget mulighed for at lave nested queries, hvilket gør, at det får en endnu større fordel i forhold til REST API'er på disse områder.

GraphQL-forespørgsel

04Platform agnostisk

Et lighedspunkt mellem REST og GraphQL er uafhængighed af platform eller programmeringssprog. Et andet fælles træk er idempotency af de samme operationer. For både REST-arkitekturen og GraphQL gælder det, at operationer som f.eks. hentning, ændring eller sletning kan anvendes gentagne gange uden at ændre resultatet.

REST vs GraphQL

05Grundlæggende elementer

De grundlæggende elementer i GraphQL er: mutation:

  • query: en grundlæggende hentningsoperation i GraphQL, som giver os mulighed for at hente data. den vigtigste forskel er, at vi får præcis de data, vi har anmodet om, ved at strukturere forespørgslen til kun at få det, vi ønsker
  • mutation: en grundlæggende datamanipulationsoperation i GraphQL, som gør det muligt at oprette, ændre eller slette data
  • skema: grundlaget for ethvert GraphQL-projekt, det beskriver logikken og funktionaliteterne, er skrevet i SDL (Schema Definition Language) og dets hovedkomponenter er typer og felter resolver: den funktion, der bruges til at forbinde dit GraphQL-skema til backend, den omdanner operationer til data og kan returnere strenge, hele tal, null og andre primitiviteter
  • resolver: resolver: den funktion, der bruges til at forbinde dit GraphQL-skema med backend'en, den omdanner operationer til data og kan returnere strenge, heltal, null og andre primitivformer
GraphQL-mutation

06Skema definitionssprog

GraphQL bruger sin egen syntaks: SDL eller Schema Definition Language. Det bruges til at specificere skemaet for et API og dets typer og felter. Typer deklareres ved hjælp af nøgleordet type, og felter tilføjes i parentes for hver objekttype.

GraphQL-skema

07Et fællesskab i vækst

GraphQL er stadig ikke lige så populær som REST, men fællesskabet vokser hurtigt. Det har allerede fået en række store brugere som GitHub, Netflix, PayPal og Shopify. Det er kun et spørgsmål om tid, før flere vil følge efter.

GraphQL-fællesskab

GraphQL

  • Hierarki: REST API'er bruger Uniform Resource Identifiers eller URI'er til at adressere ressourcer. Det betyder, at alting følger en simpel hierarkisk tilgang, hvilket er fint til små projekter, men kan give en masse problemer i større eller mere komplekse projekter.
  • Flere returrejser: På grund af den hierarkiske struktur har et REST API normalt en række slutpunkter, og klienten skal derfor foretage flere opkald for at få alle de nødvendige data.
  • Over- og underhentning: Den hierarkiske struktur og manglen på fleksible forespørgsler betyder, at REST API'er normalt enten henter for mange unødvendige data eller kræver flere kald for at få alle de nødvendige data. Dette påvirker naturligvis både båndbredde og ydeevne og forværres normalt, jo større programmet er.

REST

  • Ingen over- eller underhentning: GraphQL bruger fleksible eller endda indlejrede forespørgsler, som sikrer, at du får præcis og kun det, du har brug for. Der er ikke behov for flere opkald og ingen overskydende data, alt kan håndteres af én specifikt konstrueret forespørgsel.
  • Enkelt endepunktDet er ligeledes kun nødvendigt at have et enkelt endepunkt. Forespørgselsstrukturen vil håndtere at få det, du har brug for, og det er irrelevant, hvordan du har organiseret dataene, så længe du konstruerer forespørgslen korrekt, vil den få alt det, du har brug for, selv fra et komplet rod.
  • Type-sikkerhedGraphQL-skemaer bruger et stærkt typesystem, hvilket betyder, at alle API'er, der udsættes for klienten, er skrevet i Schema Definition Language, hvilket eliminerer datainkonsistenser og gør det meget lettere at finde fejl.
LeftCircle

Hvorfor bruge GraphQL?

Med hensyn til ydeevne er fordelen ved GraphQL indlysende, da det kun kræver et enkelt endepunkt for at levere alle ressourcerne. Det er klart, at forespørgsler kan blive ret komplekse, afhængigt af hvilke data du har brug for. Når det er sagt, er det stadig meget nemmere at vedligeholde én kompleks forespørgsel end at have et stort antal endpoints og have brug for et endnu større antal simple forespørgsler for rent faktisk at få alle de data, du har brug for fra dem. For enhver kompleks app med microservices er GraphQL simpelthen bedre end REST. For en simpel applikation er det stadig fint at bruge REST, men hvis den app nogensinde vokser sig større, vil den stå over for de samme problemer som nævnt ovenfor, og det vil være meget besværligt at omstrukturere den for at undgå dem.

Anmod om en demo

Oplev en live tilpasset demo, og find ud af, hvorfor GraphQL Editor er det rigtige valg til at sige farvel til manuelt arbejde!

Kom i gang