Når du har brug for at opbygge en API, vil dit sind sandsynligvis hoppe til HVILE, den de facto standard til oprettelse af API. Dette ændrer sig dog med stigningen i GraphQL popularitet.
Ikke alle forstår fuldt ud, hvad GraphQL handler om, eller hvorfor det bliver erklæret efterfølgeren til REST. Det er netop det, jeg vil rydde op i denne artikel. Her vil jeg vise mig GraphQLs vigtigste funktioner og fordele i forhold til REST, der fremhæver et par punkter, hvor begge adskiller sig.
Målet er at give en kort forklaring til alle, der stadig ikke har lært GraphQL at kende, afklare, hvad det gør bedre end REST for dem, der stadig er skeptiske over for denne teknologi, og i hvilke tilfælde vi skal bruge GraphQL eller REST.
GraphQL er en forespørgselssprog til API'er der muliggør deklarativ datahentning for at give klienten beføjelse til at specificere nøjagtigt de data, der er nødvendige fra API'en. Det gør det nemmere at udvikle API'er over tid.
Nu hvor vi ved, hvad GraphQL er, vil jeg præcisere, hvad det ikke er, da jeg føler, at der stadig er en vis forvirring omkring det.
For det første Det har ikke noget med databaser at gøre. Det er ikke et alternativ til SQL eller en helt ny ORM.
For det andet, det er ikke en REST-erstatning, men et alternativ. Du behøver ikke at vælge mellem det ene og det andet, de kan heldigvis eksistere sammen i det samme projekt.
Sidst men ikke mindst er GraphQL ikke kompliceret eller skræmmende. Det er ret let at forstå dets deklarative karakter og præcis, hvordan det er muligt at tage det bedste ud af det.
GraphQL blev udviklet internt af Facebook i 2012, før den blev open-source i 2015, med sin stabile version udgivet lige i juni 2018. Den 7. november 2018 blev GraphQL-projektet flyttet fra Facebook til den nyetablerede GraphQL Foundation, hostet af non-profit Linux Foundation.
Lee Byron, GraphQL's skaber, sigter mod at gøre GraphQL allestedsnærværende på tværs af webplatforme.
GraphQL bruges af hold i alle størrelser, i mange forskellige miljøer og sprog. De vigtigste virksomheder, der bruger GraphQL, er Facebook, Github, Pinterest og Shopify.
Før jeg går videre til sammenligningen med REST, vil jeg gennemgå en simpel GraphQL-forespørgsel, hvor vi kan hente en bruger såvel som hans eller hendes navn og alder:
Og JSON-svaret, vi får fra det:
Som jeg sagde tidligere, gør GraphQLs deklarative karakter det utroligt let at forstå, hvad der foregår på alle tidspunkter, da vi dybest set skriver JSON objekter uden værdier.
REST blev defineret af Roy Fielding, en computerforsker, der præsenterede REST -principperne i hans Ph.d.-afhandling i 2000.
REST (Representational State Transfer) er en software arkitektonisk stil der definerer et sæt begrænsninger, der gør enhver webtjeneste - en ægte RESTful API. REST-begrænsningerne er:
Klient-serverarkitektur betyder, at problemerne med brugergrænsefladen skal adskilles fra problemerne med datalagring for at forbedre brugergrænsefladernes portabilitet på tværs af flere platforme.
En statsløs server bevarer ingen oplysninger om den bruger, der bruger API'en. Dette betyder, at serveren ikke kan huske, om brugeren sender den første anmodning eller ej.
REST API-svar skal definere sig selv som cachelagelige eller ikke-cachelige for at forhindre klienter i at levere upassende data, der kan bruges på fremtidige anmodninger.
Et lagdelt system betyder, at hvis en proxy eller belastningsbalancerer er placeret mellem klient og server, forbindelserne mellem dem bør ikke påvirkes, og klienten vidste ikke, om der er forbundet til slutserveren eller ej.
En ensartet grænseflade antyder, at det skal være en ensartet måde at interagere med en given server på trods af enhed eller applikationstype (websted, mobilapp). Hovedretningslinjen er, at hver ressource skal identificeres på anmodninger.
I betragtning af alle REST-begrænsninger demonstrerer følgende billede REST arkitektonisk stil:
Der er to hovedårsager til, at virksomheder som Facebook, Netflix og Coursera begyndte at udvikle alternativer til REST:
1. I begyndelsen af 2010'erne var der et boom i mobilbrug, hvilket førte til nogle problemer med enheder med lavt strømforbrug og sjuskede netværk. REST er ikke optimalt til at håndtere disse problemer;
2. Efterhånden som mobilforbruget steg, steg antallet af forskellige front-end-rammer og platforme, der kører klientapplikationer. I betragtning af RESTs ufleksibilitet var det sværere at udvikle en enkelt API, der kunne passe til hver klients krav.
Hvis vi går endnu længere, indser vi, at hovedårsagen til, at en alternativ løsning blev identificeret, var fordi de fleste af de data, der bruges i moderne web- og mobilapplikationer, har en grafform. For eksempel har nyhedsstykker kommentarer, og disse kommentarer kan have funktioner som likes eller spam-flag, som oprettes eller rapporteres af brugere. Dette eksempel beskriver, hvordan en graf ser ud.
Følgelig Facebook begyndte at udvikle GraphQL. Samtidig arbejdede Netflix og Coursera også selv på alternativer. Efter Facebook open-source GraphQL droppede Coursera deres indsats og vedtog den nye teknologi. Netflix fortsatte dog med at udvikle deres eget REST-alternativ og senere open source Falcor.
I de næste afsnit vil jeg forklare, hvorfor GraphQL giver mulighed for mere fleksibilitet end REST, men lad os først se på dens arkitektur.
Er GraphQL bedre end REST? GraphQL leverer et forespørgselssprog, der giver klienter mulighed for kun at anmode om de data, de har brug for, og muliggør opdateringer i realtid. REST er afhængig af stive slutpunkter og datastrukturer. Om GraphQL er „bedre“ afhænger af de specifikke krav og fleksibilitet, der er nødvendig i et API-drevet projekt.
I dette afsnit vil jeg gå punkt for punkt gennem et praktisk eksempel, sammenligning af REST med GraphQL for at demonstrere fleksibiliteten i Facebooks forespørgselssprog.
Forestil dig, at du har en blog, og du vil have forsiden til at vise alle de seneste indlæg. For at opnå dette skal du hente indlæggene, så du vil sandsynligvis gøre noget som dette:
FÅ /api/indlæg
Men hvad nu hvis du også vil se forfatteren? Du har tre muligheder for at opnå dette:
Hver af disse tilgange vil skabe et eget problem, så lad os se på dem en efter en for at se hvordan GraphQL er i stand til at løse følgende problemer.
Med den første tilgang - at hente forfatterne fra en anden ressource - ender du med to serveranmodninger i stedet for en, og når du fortsætter med at skalere, kan du have endnu flere anmodninger til forskellige slutpunkter for at hente alle de nødvendige data.
Med GraphQL ville dette ikke ske. Du ville kun have en anmodning, og du behøver ikke at foretage flere rundture til serveren, som det ses nedenfor:
Ser man på den anden tilgang - ændring af ressourcen for også at returnere forfatteren - kan du se, at det løste problemet ret pænt. Ændring af en ressource kan dog have en sekundær effekt andre steder i din applikation. Mere præcist overafhentning.
Lad os gå tilbage til din blog, men denne gang har du også en sidebar, der viser de øverste månedlige indlæg med deres titler, undertekster og dato, der bruger ressourcen /api/indlæg. Da du ændrede ressourcen, viser den nu også forfatteren med den. Vi har dog ikke brug for det til sidebjælken.
Selvom dette måske ikke ser ud som et problem, er det ikke ideelt for brugere med begrænsede dataplaner at have et websted, der henter ubrugelige data. Siden GraphQL tillader klienten kun at hente de nødvendige data, dette problem ville ikke eksistere:
Lad os endelig se på den sidste tilgang - oprettelse af en ressource, der returnerer indlæggene med forfatteren - da det er et almindeligt mønster at strukturere slutpunkterne i henhold til visningerne i dit projekt.
Selvom dette kan løse problemer som det, der er beskrevet ovenfor, bremser det også Front-end udvikling, da hver specifik visning har brug for sit specifikke slutpunkt. Hvis et synspunkt på et tidspunkt har brug for nye data, skal udviklingen bremse, indtil slutpunktet opdateres.
Igen, da GraphQL giver klienten magt til Hent kun de nødvendige data, intet bremser, da det er meget nemt at bare tilføje et nyt felt.
Du ville få ud af dette:
Til dette:
Lad os bare lave en hurtig oversigt over forskellene mellem REST og GraphQL:
Som tidligere nævnt, GraphQL erstatter ikke REST. På trods af deres forskelle har GraphQL og REST også ligheder:
FÅanmode med en URL og returner anmodningen i JSON-data.Mutationog den Forespørgsel typer) er identisk med listen over slutpunkter i en REST API.I dag sigter næsten enhver virksomhed mod at opbygge mobile applikationer på tværs af platforme, fordi kundeinteraktionen med produktet øges markant, hvis de er i stand til at få adgang til det via deres telefoner. Når du bruger en mobilapp, forventer du, at de er lydhøre og med lav ventetid.
Ved at bruge GraphQL vil du være i stand til at nå disse mål på en virkelig nem måde. Det hjælper klienten med at hente den mængde data, der er nødvendig for at gengive en bestemt visning.
Indtil nu forestiller jeg mig, at vi deler den samme opfattelse, at GraphQL er fantastisk, men det er ikke helt sandt. Der mangler stadig nogle elementer for at gøre det perfekt. Hvis du sigter mod at have et af de næste punkter i dit projekt, bør du overveje brugen af REST.
I dag leverer hver browser en implementering af en HTTP-cache for let at undgå gendannelse af ressourcer og for at identificere, om to ressourcer er ens.
Når du bruger GraphQL, er der ingen måde at få en globalt unik identifikator for et givet objekt, fordi vi bruger den samme URL til alle anmodninger. At have cache på GraphQL skal du opsætte din egen cache.
Når du bruger REST, kan du opbygge et overvågningssystem baseret på API-svar. På GraphQL har du det ikke, fordi det altid vender tilbage 200 OK statussvar. En typisk GraphQL-fejl ser sådan ud:
Ser du på dette svar kan du se, at det er meget vanskeligt at håndtere og overvåge forskellige fejlscenarier.
Som du nu ved, kan du med GraphQL forespørge nøjagtigt, hvad du vil, når du vil, men vi skal være opmærksomme på, at dette fører til komplekse sikkerhedsimplikationer. Hvis en ondsindet aktør forsøger at indsende en dyr indlejret forespørgsel for at overbelaste din server eller database, og din server ikke har den rigtige beskyttelse, vil du være sårbar over for DDoS (Denial-of-Service-angreb) angreb.
Nu hvor vi ved, hvordan det står i forhold til REST, lad os tale om nogle af de funktioner, der er unikke for GraphQL.
GraphQL bruger sit eget typesystem til at definere skemaet for en API, med dens syntaks kaldet Skemadefinitionssprog (SDL). Skemaet fungerer som en kontrakt mellem serveren og klienten for at definere, hvordan en klient kan få adgang til dataene.
Når skemaet er defineret, frontenden og bagenden teams kan arbejde uafhængigt, da frontenden let kan testes med mock-data. Front-enden kan også få nyttige oplysninger fra skemaet, såsom dets typer, forespørgsler og mutationer ved hjælp af GraphiQL eller introspektion. Den GraphQLs skema giver også typesikkerhed, hvilket er et plus for front-end- og back-end-udviklingen, da det fanger typefejl tidligt.
Et skemaeksempel:
GraphQL IDE er en af de mest nyttige funktioner i GraphQL-udvikling. Det drager fordel af sin selvdokumenterende natur for at gøre udviklingen til en leg.
Brug af GraphiQL eller GraphQL Legeplads, du kan bare inspicere dit skema og endda køre forespørgsler og mutationer for at teste din API.
GraphQL giver et glat og hurtigt udviklingsmiljø med sin deklarative og fleksible karakter, der tilbyder mange forbedringer i forhold til REST.
Det har allerede et stort samfund og et levende økosystem, og blev allerede implementeret i Flere populære sprog, såsom JavaScript, Gå og Java.
Mens dette indlæg kun dyppede tæerne i havet, der er GraphQL, er det hjemmeside har en overflod af information og er et fantastisk sted at lære og begynde at bruge GraphQL.
Hvis du sigter mod udvikle en API, der skal bruges på en mobilapplikation du skulle have GraphQL som første mulighed fordi båndbreddebrug betyder noget. Hvis din applikation kræver en robust API, med caching og et overvågningssystem du skal gå med REST.
Når alt dette er sagt, er det ikke en perfekt teknologi, og det har stadig et par ulemper sammenlignet med REST. Men i betragtning af hvor ung den er, ser fremtiden utrolig lys ud for GraphQL.
Webudvikler, der almindeligvis skriver null i stedet for nul. Elsker at udforske Javascripts funktionelle stil.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
