Många arkitektoniska standarder med öppen källkod finns för att bygga och distribuera applikationer. REST (Representational State Transfer), SOAP (Simple Object Access Protocol), RPC (Remote Procedural Call) och GraphQL API är de mest populära.

RESTful API: er är den mest använda API-arkitektoniska standarden. Om du har skrivit komplexa RESTful API: er med många slutpunkter, har du förmodligen insett hur komplicerade de kan vara. Detta gäller särskilt om det bara finns små skillnader mellan ändpunkterna.

Du kan också stöta på problem med datahämtning eftersom RESTful API: er inte är tillräckligt flexibla för att välja specifik data. GraphQL löser dessa problem med RESTful API: er.

Vad är GraphQL?

GraphQL (Graph Query Language) är ett frågespråk och körtid för att bygga API: er. Till skillnad från REST API: er med många slutpunkter för att konsumera data, har GraphQL API: er en ingångspunkt. Du kan hämta specifik data genom att beskriva den i frågor.

De GraphQL-specifikation definierar frågespråket och hur GraphQL-servrar fungerar. Du kan bygga och konsumera GraphQL API: er på serversidaspråk från Python till

instagram viewer
Javascriptoch alla språk som stöder HTTP.

Meta byggde GraphQL 2012 som ett alternativ till REST för att bygga på HTTP. De släppte GraphQL som en öppen källkodsstandard 2015. Idag övervakar GraphQL-stiftelsen utvecklingen av GraphQL-specifikationen.

GraphQL är ganska nytt, med låg användning, och det finns dolda kostnader för att använda det. Att bygga GraphQL API: er kan vara onödigt komplicerat, särskilt för små projekt med ett fåtal slutpunkter.

Dessutom returnerar alla GraphQL-förfrågningar så småningom en statuskod på 200 oavsett status för begäran.

Hur fungerar GraphQL?

Till skillnad från REST, som är resursinriktat, GraphQL kräver att du tänker på data som en graf för att interagera med data. Du kan ange strukturen för data, och specifikationen ger ett robust frågegränssnitt för interaktion med API: t över HTTP. Du kommer att kunna använda olika funktioner beroende på GraphQL-paket eller bibliotek du väljer att använda.

GraphQL-scheman inkluderar objekttyper som definierar det begärbara objektet och dess tillgängliga fält. På API-frågor och mutationer validerar GraphQL-paketet frågor och exekverar frågorna baserat på de angivna hanterarfunktionerna (resolvers).

Varför ska du använda GraphQL?

REST är en lättanvänd standard och de flesta programmeringsspråk har verktyg för att snabbt bygga RESTful API. Det finns dock många problem med att bygga och konsumera RESTful API: er.

Här är några av problemen med REST som gör att utvecklare föredrar GraphQL för vissa användningsfall.

Ineffektiv datahämtning

RESTful API: er vidarebefordrar data baserat på endpointens specifikation. De är inte tillräckligt flexibla för att hämta data utöver vad som är hårdkodat i slutpunktens hanterarfunktion.

Anta att en slutpunkt returnerar en lista med data vid anrop och att du måste ange värden eller kriterier för fält. I så fall måste utvecklaren skapa en slutpunkt och definiera affärslogiken för att returnera data. Du kan analysera den värdefulla resursen manuellt, vilket så småningom tar längre tid.

GraphQL löser problemet med ineffektiv datahämtning eftersom du kan fråga API: er för att returnera data baserat på kriterier och specifikationer flexibelt.

GraphQL API: er är interaktiva; du kan ange vilken data du behöver för att hämta i en enkel, läsbar syntax.

{
 användare (där: {ålder: {_eq: "89"}}) { 
 namn
skola(var: {Levande: {_eq: true}}) {
 bio
 nationalitet
 }
 }
}

GraphQL-frågan ovan frågar a användare schema för poster där ålder fältet är 89. Frågan har en inbäddad fråga för poster där Levande fältet utvärderar Sann. Det returnerar namn, biografi och nationalitetsfält från schemat.

Snabb utveckling

Att bygga och konsumera GraphQL API: er är enklare än att använda REST, särskilt när projektstorleken ökar. Under utvecklingsfasen behöver du inte utveckla så många rutter och hanterarfunktioner som du kommer att göra när du utvecklar RESTful API: er. Att konsumera GraphQL API: er är inte lika tråkigt som RESTful API: er.

I REST ger olika slutpunkter åtkomst till olika resurser, till skillnad från GraphQL, där det finns en enda slutpunkt. Detta ger flexibilitet och prestanda, och frågor kan anropa olika resolverfunktioner.

GraphQL Schema Definition Language

GraphQL Schema Definition Language (SDL) anger scheman för GraphQL-tjänster.

GraphQL SDL-syntaxen är lätt att läsa och förstå. Du anger strukturen för ditt schema i en fil med .graphql eller .graphqls förlängning.

typ mänsklig {
 namn: Sträng!
 ålder: Int!
}
input AddHuman {
 namn: Sträng!
 ålder: Int!
}


typ mutation {
 CreateHuman (ingång: AddHuman!): Human!
 DeleteHuman (id: Int!): Sträng!
 UpdateHuman (id: Int!): Sträng!
}
typ Fråga {
 GetHuman (id: Int!): Människan!
GetHumans: [Mänsklig!]!
}

GraphQL-koden ovan är schemat för ett GraphQL API som definierar strukturen för API: et för förfrågningar. Schemat definierar CRUD-funktionalitet för API.

På klientsidan kan klienten, baserat på schemats struktur och klientens data eller operation, exekvera en fråga (GET eller DELETE i REST) ​​eller a mutation (PUT eller POST).

Här är ett exempel på att fråga efter Mänsklig schema.

fråga Human {
 namn
 ålder
}

Frågan ovan skulle returnera det mänskliga schemat namn och ålder fältdata.

GraphQL-mutationer har en ganska annorlunda syntax i motsats till frågor. Här är ett exempel på mutationsoperation på Mänsklig schema.

mutation {
 CreateHuman (ingång:{ namn:"man", ålder: 1000000000000000,}) {
 namn
 ålder
 }
}

Mutationskoden matas in namn och ålder fält till klienten och returnerar data från fälten.

Du behöver ett datalager för uthållighet när du bygger ditt GraphQL API. Precis som REST och de flesta HTTP-baserade webbarkitekturer är GraphQL tillståndslös, och du kan använda vilken databutik eller databas som helst för din app.

Bygga ett GraphQL API

GraphQL är en specifikation och du kan bygga GraphQL på de mest populära språken på serversidan. Du måste hitta ett bibliotek med de funktioner du behöver för ditt projekt.

När du väljer ett GraphQL-bibliotek vill du använda ett funktionsrikt bibliotek som stöder alla GraphQL-typer och operationer. De flesta bibliotek använder antingen ett schema-först eller ett kod-först tillvägagångssätt. I det förstnämnda definierar du ett GraphQL-schema, och biblioteket genererar resolvers och boilerplate-kod. För det senare hårdkodar du resolversna utan att definiera ett schema.

GraphQL börjar bli adopterad

Sedan starten av GraphQL har utvecklare och företag släppt verktyg för att förenkla dess användning. Dessa kan minska utvecklingstiden för mindre och medelstora projekt.

Du kan kolla in GraphQL-klienter med öppen källkod, GraphQL-dokumentationen och dess specifikation för att lära dig mer.