I en undersökning som genomfördes med personer som arbetar med Application Programming Interfaces (API) genomfördes, sa 33,4 % av de tillfrågade att GraphQL är en av de mest spännande teknikerna att välja på.
GraphQL är utvecklat av Facebook som ursprungligen tillämpades för mobilapplikationer 2012. 2015 lades GraphQL-specifikationer ut på entreprenad, som nu administreras av GraphQL Foundation.
Vad är GraphQL och varför är det viktigt för dina moderna API:er?
GraphQL är ett frågespråk och körtid på serversidan för API:er och en körtid för att uppfylla frågorna med dina befintliga data. Om du behöver ha en fullständig förståelse för data i ditt API, är GraphQL det bästa du kan göra!
Med GraphQL kommer kunder att ha möjligheten att bara skaffa det de behöver och varken mer eller mindre. GraphQL styr data och inte servern, och det ger alltid förutsägbara resultat! Detta gör API:er lätt flexibla, snabba och utvecklar vänliga.
Termer relaterade till GraphQL:
- Schema: Alla möjliga data som en klient kan fråga genom en viss tjänst kan beskrivas av API-utvecklare genom att skapa ett schema i GraphQL. Ett schema består av objekttyper, dvs den typ av objekt som kan begäras och de fält som det kommer att inkludera.
- Frågor: I GraphQL ska frågor valideras mot schemana, och först då kommer de validerade frågorna att köras.
- Resolver: Resolver är en funktion till vilken utvecklaren bifogar varje fält i ett schema, där varje generator genererar ett visst värde.
Vilka är de beslut som en API-utvecklare tar när det gäller GraphQl? Tja, förutom att definiera och validera syntax för API-frågor, från graphql-spec-förrådet, styrs de flesta andra beslut av API-designern. GraphQL ger inga anvisningar om hur man lagrar data och utvecklare kan använda vilket programmeringsspråk som helst som JavaScript, PHP, Python, Ruby med flera.
Ur en klients synvinkel är de mest generiska GraphQL-operationerna förmodligen frågor och mutationer. Prioriteten för dessa operationer kan representeras i form av Skapa, Läs, Uppdatera och Ta bort (CRUD)-modellen, där Query motsvarar Reading och Mutations som motsvarar Skapa, Uppdatera och Ta bort.
Vilka är fördelarna med GraphQL?
Om du planerar att prova GraphQL i en företags- eller företagsmiljö, här är några anledningar till en positiv nickning:
- GraphQL gör det möjligt för en organisation att sammankoppla hela sitt API och GraphQL-schemat sätter en enda källa till sanning i en GraphQL.
- På en enda tur och retur hanteras GraphQL-samtal och kunder får de förfrågningar de vill ha utan återhämtning.
- Datatyper är starkt definierade så det finns inga kommunikationsproblem mellan klienten och servern.
- GraphQL är idealisk för att automatiskt generera dokument på grund av dess introspektiva funktion där klienterna kan begära en lista över datatyper.
- Utan att bryta befintliga frågor kan ett applikations-API utvecklas i GraphQL.
- Funktioner som inte är tillgängliga med Rest API kan nås från GraphQL-tilläggen med öppen källkod.
- En speciell applikationsarkitektur behöver inte diskuteras, utan introduceras ovanpå ett redan existerande Rest API och är fungerande med befintliga API-hanteringsverktyg.
Vad är GraphQL bästa praxis?
GraphQL-specifikationerna är avsiktligt outtalade för många kritiska frågor som API står inför relaterade till nätverk, auktorisering och sidnumrering. Det betyder inte att GraphQL inte har några lösningar på dessa problem, utan det betyder helt enkelt att dessa problem ligger utanför beskrivningen av GraphQL.
De bästa metoderna som nämns i det kommande avsnittet är taktiska förslag för att lösa återkommande problem som servering över HTTP och auktorisering.
HTTP
Medan Rest API använder en uppsättning webbadresser som exponerar en enskild resurs, serveras GraphQL vanligtvis över HTTP genom en enda slutpunkt som avser en fullständig uppsättning tjänster möjligheter. GraphQL kan användas tillsammans med en uppsättning resurs-URL:er men kommer att vara lite inkompatibel med verktyg som GraphiQL.
JSON GZIP
Trots att JSON GZIP inte finns i GraphQL-specifikationerna, svarar den vanligtvis på den. JSON är ett välbekant ramverk för såväl klienter som API-utvecklare, som är lätt att läsa och felsöka. GraphQL-syntaxen är delvis inspirerad av JSON-syntaxen.
Versionering
GraphQL undviker versionshantering genom att tillhandahålla motståndskraftiga verktyg för den kontinuerliga utvecklingen av ett GraphQL-schema, även om GraphQL på alla sätt kan versioner som alla andra REST API.
Det kommer endast att finnas begränsad kontroll över data som returneras från en API-slutpunkt, alla ändringar kan antas vara en brytande ändring som kräver en ny version. Det blir svårt att förstå och underhålla ett API när nya funktioner och ständiga utgåvor läggs till. GraphQL har ett annat sätt att hantera detta – det returnerar den data som är explicit efterfrågad, utan att skapa en brytande förändring genom att lägga till nya typer och nya fält på dessa typer. Därför är denna praxis den mest valda för att undvika att bryta ändringar och servera en version mindre API.
Nullbarhet
Som standard har GraphQL-systemet nullbara fält. När nätverket stöds av databaser och andra tjänster finns det chanser att en databas kraschar eller att en asynkron åtgärd misslyckas eller att ett undantag tas bort. När fält är nullbara som standard, skulle fälten returnera “null” istället för att en begäran misslyckas på grund av ovannämnda skäl. I fallet med GraphQL, när en klient ställer en begäran om ett icke-nullfält, kommer den aldrig att returnera null, utan kommer istället att ställa in det överordnade fältet till “null” när ett fel uppstår.
Under designfasen av GraphQL-schemat måste designern ta hand om de potentiella problemen om “null” är inställt som lämpligt värde för ett misslyckat fält.
Paginering
I GraphQL kan vissa fält returnera en lista med värden. Men -pagineringen av längre värdelistor överlåts till API-designerns beslut. GraphQL har många API-designmöjligheter för paginering som kommer med en kombination av för- och nackdelar.
Funktions Effektiva API: er banade vägen för ett bästa praxis mönster som kallas Connections. Anslutningsverktyg för klienter som Relay kan därför ge automatiskt stöd för paginering från klientsidan när detta mönster integreras av GraphQL.
Batchning och cachning
på serversidan Ren Koder kan skrivas på serversidan med hjälp av GraphQL där varje fält på varje typ har en fokuserad på en funktion för värde upplösning. Det kan dock förekomma upprepad dataladdning från dina servrar om GraphQL-tjänsten är oerfaren eller naiv. När det finns så många data förfrågningar från backend under en kort period till en underliggande databas eller mikro tjänst, har batch tekniken valt, och för detta verktyg som Data Loader från Facebook.
Slutnot:
Varför ska företag välja GraphQL? GraphQL är en stark möjliggörare för både API-utvecklare och konsumenter eftersom:
- Genom ett enhetligt API kan organisationer med flera team och system göra sin data tillgänglig enkelt.
- Det finns ingen under hämtning eller inhämtning av data och kan endast hämta den nödvändiga informationen över de relaterade enheterna.
- Den har en självdokumenterande funktion som hjälper till att inspektera och prova API:er med minimala ansträngningar.
- Den är uppbyggd kring ett typsystem som visar namn och typ av varje fält tillsammans med relationer med olika enheter.
- Det kan uppmuntra olika tillvägagångssätt för API-modifieringar.
Vill du bygga ett utvecklingsbart och frågekort API? Då är GraphQL rätt val. Med GraphQL kommer det att vara minimal komplexitet involverad för interna system för datahämtning. Den använder ett typsystem som leder till automatisk och uppdaterad API-dokumentation hela tiden. Dessutom är dess verktyg och ekosystem det som kvalificerar GraphQL som ett potentiellt verktyg inte bara för utvecklarna, utan även för dina kunder.
