Mange åpen kildekode-arkitektoniske standarder eksisterer for å bygge og distribuere applikasjoner. REST (Representational State Transfer), SOAP (Simple Object Access Protocol), RPC (Remote Procedural Call) og GraphQL APIer er de mest populære.

RESTful APIer er den mest brukte API-arkitektoniske standarden. Hvis du har skrevet komplekse RESTful APIer med mange endepunkter, har du sannsynligvis innsett hvor kompliserte de kan være. Dette gjelder spesielt hvis det kun er små forskjeller mellom endepunktene.

Du kan også støte på problemer med datahenting siden RESTful APIer ikke er fleksible nok til å velge spesifikke data. GraphQL løser disse problemene med RESTful APIer.

Hva er GraphQL?

GraphQL (Graph Query Language) er et spørringsspråk og kjøretid for å bygge APIer. I motsetning til REST APIer med mange endepunkter for forbruk av data, har GraphQL APIer ett inngangspunkt. Du kan hente spesifikke data ved å beskrive dem i spørringer.

De GraphQL-spesifikasjon definerer spørringsspråket og hvordan GraphQL-servere fungerer. Du kan bygge og konsumere GraphQL APIer på serversidespråk fra Python til

Javascript, og alle språk som støtter HTTP.

Meta bygde GraphQL i 2012 som et alternativ til REST for å bygge på HTTP. De ga ut GraphQL som en åpen kildekode-standard i 2015. I dag overvåker GraphQL-stiftelsen utviklingen av GraphQL-spesifikasjonen.

GraphQL er ganske nytt, med lav adopsjon, og det er skjulte kostnader ved å bruke det. Å bygge GraphQL APIer kan være unødvendig komplisert, spesielt for små prosjekter med noen få endepunkter.

Alle GraphQL-forespørsler returnerer til slutt en statuskode på 200 uavhengig av forespørselens tilstand.

Hvordan fungerer GraphQL?

I motsetning til REST, som er ressursorientert, GraphQL krever at du tenker på data som en graf for å samhandle med data. Du kan spesifisere strukturen til dataene, og spesifikasjonen gir et robust spørringsgrensesnitt for interaksjon med API over HTTP. Du vil kunne bruke ulike funksjoner avhengig av GraphQL-pakke eller bibliotek du velger å bruke.

GraphQL-skjemaer inkluderer objekttyper som definerer det forespørselbare objektet og dets tilgjengelige felt. På API-spørringer og mutasjoner validerer GraphQL-pakken spørringer og utfører spørringene basert på de spesifiserte behandlerfunksjonene (resolvere).

Hvorfor bør du bruke GraphQL?

REST er en enkel å bruke standard, og de fleste programmeringsspråk har verktøy for å bygge RESTful APIer raskt. Imidlertid er det mange problemer med å bygge og konsumere RESTful APIer.

Her er noen av problemene med REST som gjør at utviklere foretrekker GraphQL for noen brukstilfeller.

Ineffektiv datahenting

RESTful APIer videresender data basert på endepunktets spesifikasjon. De er ikke fleksible nok til å hente data utover det som er hardkodet i behandlerfunksjonen til endepunktet.

Anta at et endepunkt returnerer en liste over data ved anrop, og du må spesifisere verdier eller kriterier for felt. I så fall må utvikleren opprette et endepunkt og definere forretningslogikken for å returnere dataene. Du kan analysere den verdifulle ressursen manuelt, noe som til slutt tar mer tid.

GraphQL løser problemet med ineffektiv datahenting siden du kan spørre APIer for å returnere data basert på kriterier og spesifikasjoner fleksibelt.

GraphQL APIer er interaktive; du kan spesifisere dataene du trenger for å hente i en enkel, lesbar syntaks.

{
 bruker (hvor: {alder: {_eq: "89"}}) { 
 Navn
skole(hvor: {i live: {_eq: true}}) {
 bio
 nasjonalitet
 }
 }
}

GraphQL-spørringen ovenfor spør en bruker skjema for oppføringer der alder feltet er 89. Spørringen har en innebygd spørring for oppføringer der i live felt vurderer ekte. Den returnerer feltene navn, bio og nasjonalitet fra skjemaet.

Rask utvikling

Å bygge og konsumere GraphQL APIer er enklere enn å bruke REST, spesielt ettersom prosjektstørrelsen øker. Under utviklingsfasen trenger du ikke utvikle så mange ruter og behandlerfunksjoner som du vil når du utvikler RESTful APIer. Å konsumere GraphQL APIer er ikke så kjedelig som RESTful APIer.

I REST gir forskjellige endepunkter tilgang til forskjellige ressurser, i motsetning til GraphQL, hvor det er ett enkelt endepunkt. Dette gir fleksibilitet og ytelse, og spørringer kan kalle forskjellige løserfunksjoner.

GraphQL Schema Definition Language

GraphQL Schema Definition Language (SDL) spesifiserer skjemaene for GraphQL-tjenester.

GraphQL SDL-syntaksen er lett å lese og forstå. Du spesifiserer strukturen til skjemaet ditt i en fil med .graphql eller .graphqls Utvidelse.

type menneskelig {
 Navn: String!
 alder: Int!
}
input AddHuman {
 Navn: String!
 alder: Int!
}


type Mutasjon {
 CreateHuman (inngang: AddHuman!): Human!
 DeleteHuman (id: Int!): String!
 UpdateHuman (id: Int!): String!
}
type Søk {
 GetHuman (id: Int!): Menneske!
GetHumans: [Menneskelig!]!
}

GraphQL-koden ovenfor er skjemaet for en GraphQL API som definerer strukturen til APIen for forespørsler. Skjemaet definerer CRUD-funksjonalitet for API.

På klientsiden, basert på skjemaets struktur og klientens data eller operasjon, kan klienten utføre en spørsmål (GET eller DELETE i REST) ​​eller a mutasjon (PUT eller POST).

Her er et eksempel på å spørre etter Menneskelig skjema.

spørring Human {
 Navn
 alder
}

Spørringen ovenfor ville returnere det menneskelige skjemaet Navn og alder feltdata.

GraphQL-mutasjoner har en ganske annen syntaks i motsetning til spørringer. Her er et eksempel på en mutasjonsoperasjon på Menneskelig skjema.

mutasjon {
 CreateHuman (inndata:{ navn:"Mann", alder: 1000000000000000,}) {
 Navn
 alder
 }
}

Mutasjonskoden legges inn Navn og alder feltene til klienten og returnerer dataene fra feltene.

Du trenger et datalager for utholdenhet når du bygger GraphQL API. Som REST og de fleste HTTP-baserte nettarkitekturer, er GraphQL statsløs, og du kan bruke hvilken som helst datalagring eller database for appen din.

Bygge et GraphQL API

GraphQL er en spesifikasjon, og du kan bygge GraphQL på de mest populære serversidespråkene. Du må finne et bibliotek med funksjonene du trenger for prosjektet ditt.

Når du velger et GraphQL-bibliotek, vil du bruke et funksjonsrikt bibliotek som støtter alle GraphQL-typer og operasjoner. De fleste biblioteker tar enten en skjema-først eller en kode-først tilnærming. I førstnevnte definerer du et GraphQL-skjema, og biblioteket genererer resolvere og boilerplate-kode. For sistnevnte hardkoder du resolverne uten å definere et skjema.

GraphQL er i ferd med å bli tatt i bruk

Siden oppstarten av GraphQL har utviklere og selskaper gitt ut verktøy for å forenkle bruken. Disse kan redusere utviklingstiden for mindre og mellomstore prosjekter.

Du kan sjekke ut GraphQL-klienter med åpen kildekode, GraphQL-dokumentasjonen og spesifikasjonene for å lære mer.