Hvad er GraphQL? Almindelige myter debunked.

Jeg elsker at tale om GraphQL, især med folk, der har arbejdet med GraphQL eller tænkt på at vedtage GraphQL. Et almindeligt spørgsmål, folk har, er, hvorfor nogen ønsker at flytte til GraphQL fra REST.

Der er masser af ressourcer derude, der taler om forskellen mellem REST og GraphQL, og de er gode at tjekke ud, hvis du er interesseret i, hvordan disse to er forskellige. I dette blogindlæg vil jeg tage fat på nogle almindelige misforståelser og spørgsmål, der stilles om GraphQL.

Hvordan drager du fordel af GraphQL i frontenden?

Som Front End Engineer kan jeg godt lide at arbejde med en GraphQL API af følgende grunde:

  1. Du kan straks teste forespørgsler og mutationer ved hjælp af GraphiQL eller legeplads
  2. Mindre data betyder lettere statsstyring
  3. Det aflæsser tunge løft til serveren gennem resolvere
  4. Det har dokumentation, der er opdateret og interaktiv

Hvordan er det bedre end REST?

  1. Der er et slutpunkt til at hente alle ressourcer.
  2. Du undgår overhentning af data (at få for mange felter, når kun et par felter er nødvendige).
  3. Du undgår at hente data (at skulle ringe til flere API'er, fordi en API ikke giver alle de nødvendige oplysninger tilbage).

Myte: GraphQL bruges til at forespørge grafdatabaser.

GraphQL kan bruges til at forespørge om en grafdatabase, men dette er ikke den eneste brugssag. "Grafen" i GraphQL bruges til at repræsentere den graflignende struktur af data. Du modellerer dataene med hensyn til noder og hvordan de forbinder til hinanden. Skema bruges til at repræsentere denne modellering.

Der er ingen begrænsning i GraphQL-specifikationen, der tvinger, at datakilden skal være en graf.

Myte: GraphQL fungerer kun med databaser eller datakilder, der er grafbaserede.

Det er en misforståelse, at du skal omskrive din database for at vedtage GraphQL. GraphQL kan være en indpakning omkring enhver datakilde, herunder databaser. GraphQL er en query language for your API- hvilket betyder, at det er en syntaks for, hvordan man beder om data.

Myte: Data hentning med resolvere, forespørgsler og mutationer fungerer magisk.

Du bliver nødt til at definere nøjagtigt, hvad hver af dem skal gøre. Du skriver funktioner, der bliver kaldt, når forespørgsler udløses, og skriver funktioner til opløsere, der sender nøjagtigt de data tilbage, du har brug for, og ved, hvilken API der skal ringes til. Du definerer, hvilke data der returneres gennem disse funktioner ved at kalde opløsere.

Myte: GraphQL erstatter Redux eller ethvert statsstyringsbibliotek

Redux er et statsforvaltningsbibliotek. GraphQL er ikke et statsstyringsbibliotek. GraphQL hjælper med at få færre data, hvilket igen fører til færre data at administrere på klientsiden, men det er ikke en statsstyringsløsning.

Du bliver stadig nødt til at styre staten - omend på en mere let måde. Klientbiblioteker som Apollo og Relay kan bruges til at styre tilstand, og de har indbygget cache. GraphQL er ikke en erstatning for Redux - det hjælper med at reducere behovet for det.

Myte: GraphQL er et databasesprog.

GraphQL er et programmeringssprog - specifikt et forespørgselssprog. GraphQL's specifikation definerer, hvordan GraphQL-driftstider skal implementere sproget, og hvordan data skal kommunikeres mellem klient og server.

GraphQL bruges til at bede om data og kan bruges flere steder i ethvert lag fra forenden til bagenden. Der er databaser som DGraph, der implementerer GraphQL-spec, så klienter kan bruge GraphQL til at søge i databasen.

Myte: Du kan ikke have REST-slutpunkter i din implementering med GraphQL.

Du kan tilslutte flere REST-slutpunkter eller endda flere GraphQL-slutpunkter i din applikation. Selvom det ikke er en bedste praksis at have flere REST-slutpunkter, er det teknisk muligt.

Myte: GraphQL er svært at introducere i et eksisterende projekt.

GraphQL kan sættes i et eksisterende projekt. Du kan starte med en komponent af forretningslogik, tilslutte et GraphQL-slutpunkt og begynde at hente data via GraphQL. Du behøver ikke at skrabe et helt projekt for at begynde at bruge GraphQL.

Hvis det stadig er en skræmmende opgave at skifte til GraphQL-slutpunkt, kan du starte med at maskere et REST-slutpunkt i et GraphQL-slutpunkt ved hjælp af resolvere.

Myte: GraphQL er kun til front-end-udviklere

GraphQL er agnostisk platform. Efter min mening starter skønheden ved GraphQL's fordele indefra og ud - bagenden til frontenden.

Som back-end-udvikler er du i stand til at udvide API'en ved at tilføje felter uden at skulle offentliggøre en ny version af API'en. Du behøver ikke at skrive forskellige slutpunkter til forskellige behov, da klienter kan hente de data, de har brug for.

Med GraphQL har du synlighed over, hvilke felter klienter bruger, hvilket giver kraftfuld instrumentering.

Myte: GraphQL skriver selv databaseforespørgsler, jeg skal bare specificere skemaer og forholdet mellem dem

Det kan være nødvendigt at skrive databaseforespørgslerne afhængigt af hvilket GraphQL-bibliotek, du bruger. Imidlertid skriver nogle biblioteker som Neo4j og Prisma databaseforespørgsler og abstraherer logikken væk fra udvikleren. Alt inklusive resolvere, forespørgsler og mutationer skal defineres.

Myte: GraphQL bruges til at tegne grafer.

Ofte tror folk, der ikke er nye i GraphQL, at det er en grafplottesoftware som D3. GraphQL plotter ikke grafer.

Myte: GraphQL kræver komplicerede klienter og er næsten umuligt at gøre med en simpel HTTP-hentning

Myte: Det erstatter ORM'er.

For nylig ser vi en masse DB og GraphQL integration, men GraphQL i sig selv er ikke det.

Jeg synes, GraphQL er fantastisk! Der er en lang række biblioteker, der hjælper en bruger i gang med GraphQL. Hvis du er interesseret i at lære om GraphQL, skal du starte med dokumentationen eller tjekke dette Udemy-kursus, som jeg fandt nyttigt, da jeg var ny i GraphQL.

Jeg erklærer en krig!

var krig; #DevJoke

- Shruti Kapoor (@ shrutikapoor08) 12. december 2019