Hva er GraphQL?
GraphQL er en alternativ måte å kommunisere med APIer på som passer godt for komplekse datastrukturer og bygging av grensesnitt på toppen av dem. I stedet for å behandle data som separate, frittstående deler, viser GraphQL hvordan datadeler kobler seg sammen og forholder seg til hverandre, noe som gjør det enkelt å spørre etter og motta informasjon.
Tenk på GraphQL som et spørrespråk som lar deg snakke med APIen som om du snakket direkte med databasen. Ved å bruke GraphQL kan du komme så nær databasen som mulig, slik at du kan plukke og velge hvilke data du vil ha og hvordan du får dem, noe som gir en massiv ytelsesfordel.
GraphQL ble opprettet av Facebook for å løse problemet med å skalere med komplekse datastrukturer. Som et resultat av deres vellykkede bruk av det, har flere og flere bedrifter begynt å innse fordelene ved å bruke GraphQL for APIene deres.
Kjenner du allerede REST? GraphQL vil føles kjent.
GraphQL APIer er lettere å arbeide med enn du kanskje tror. Hvis du er vant til å arbeide med REST APIer, er her hvordan kjernekonsepter fra REST oversettes til GraphQL.
| Funksjon↕ | REST↕ | GraphQL↕ |
|---|---|---|
| Endepunkt | Forespørsler gjøres til flere endepunkter for forskjellige handlinger | Alle forespørsler gjøres til ett enkelt endepunkt (f.eks. /graphql) |
| Datahenting | Bruk GET-metoder på spesifikke endepunkter for å hente data | Bruk spørringer for å be om nøyaktig dataene som trengs, noe som reduserer over-henting eller under-henting |
| Datamodifisering/handlinger | Bruk HTTP-metoder som POST, PUT, PATCH eller DELETE for å endre eller behandle data. | Bruk mutasjoner for å utføre operasjoner (f.eks. opprette parter, beregne landingskostnader) |
| Responsformat | Faste responsformater returnerer alle forhåndsdefinerte felt, uavhengig av om de trengs | Fleksible responser tillater spesifisering av nøyaktig hvilke felt som skal inkluderes, noe som reduserer unødvendig dataoverføring (Hvis denne fleksibiliteten føles komplisert, kan du ganske enkelt bruke de forhåndsskrevne spørringseksemplene i dokumentasjonen vår for en REST-lignende opplevelse) |
| Dataforbindelse | Flere forespørsler er ofte påkrevd for å hente relaterte data | Nestede spørringer gjør det mulig å hente relaterte data i én forespørsel (f.eks. partidetaljers og forsendelsessjekkdetaljer sammen). Brukere kan også bygge arbeidsflyter for å administrere flere mutasjoner innenfor en enkelt GraphQL-forespørsel, noe som reduserer kompleksitet og forbedrer effektivitet |
Fordeler med GraphQL
Raskere responser
GraphQL gir raskere responser gjennom presis datahenting, bruk av et enkelt endepunkt og forbedrede muligheter for batching og caching.
Presis datahenting
En vanlig utfordring med REST er over-henting eller under-henting av data – enten få for mye unødvendig informasjon eller ikke nok av det som trengs på en gang. GraphQL eliminerer dette ved å tillate forespørsler om nøyaktig det som trengs – ikke mer, ikke mindre. Denne spesifisiteten forbedrer ikke bare ytelsen, men forenkler også prosessen for de som samhandler med APIen, noe som gjør systemet mer effektivt og brukervennlig.
Eksempler på hvordan dette er nyttig:
- Dette gjør at frontend-utviklere kan hente nøyaktig dataene de trenger for UI-komponentene sine, noe som reduserer antall tur-returner til serveren og forbedrer ytelsen.
- Tenk deg at du vil få en HS-kodeklassifisering, kartonisering, forsendelsesrating og tilbud om landingskostnad på varer i en handlekurv. Hvis du er integrert via GraphQL API, kan du foreta ett enkelt anrop med de nødvendige arbeidsflytene for å få alt du trenger (og ingenting du ikke trenger) i ett svar. Derimot, med REST APIer, ville du først måtte ringe Classify REST API, deretter ringe Rating REST API separat etterpå, og til slutt koble den klassifiseringen og forsendelsesratingen inn i ditt tredje anrop til Landed Cost REST API. Alle disse REST APIene ville returnere alle informasjoner de kan, noe som fører til at du må analysere gjennom responsen for dataene du trenger. Disse sparesamfunnene i hastighet har en effekt på raskhet å returnere en komplett landingskostnad, før kunden forlater.
Enkelt endepunkt
GraphQL APIer har vanligvis ett enkelt endepunkt, i motsetning til REST APIer som ofte har flere endepunkter for forskjellige ressurser og handlinger. Dette gjør det enklere å administrere og forstå APIen.
Batching og caching
GraphQLs evne til å samle spørringer og dens støtte for caching-strategier fører til betydelige ytelsesforbedringar. Disse funksjonene reduserer belastningen på nettverk og servere, noe som resulterer i raskere og mer pålitelige interaksjoner for brukere.
Velinformerte skjemaer
GraphQL APIer er basert på et sterkt typet skjema. Dette skjemaet definerer strukturen til tilgjengelige data og operasjonene som kan utføres. Dette gir klarhet om hvilke data som er tilgjengelig og hvordan du får tilgang til dem, noe som kan forbedre utviklernes produktivitet og redusere feil. For eksempel kan frontend-lag utforske grafen for å få nøyaktig det de trenger i stedet for å vente på et nytt REST-endepunkt.
Mulighet til å forbedre uten å bryte eksisterende klienter
Å legge til nye funksjoner eller endre eksisterende i GraphQL forstyrrer ikke gjeldende integreringer, takket være dens fleksible spørringsstruktur. Denne muligheten sikrer at forbedringer kan gjøres uten å bryte kompatibilitet med eksisterende klienter.
Oppdatert dokumentasjon
Takket være GraphQLs introspeksjonsfunksjon genereres dokumentasjonen automatisk og oppdateres med hver endring. Dette sikrer at all informasjon som gis til utviklere, er oppdatert, noe som reduserer integreringsproblemer og støttetickets relatert til utdatert dokumentasjon – en utfordring som vanligvis oppstår med REST API-dokumentasjon.
Se vår GraphQL-dokumentasjon og vår REST-dokumentasjon for å se forskjellen.
En analogi
Tenk deg at du er på en restaurant med en meny som lar deg bestille retter nøyaktig slik du liker dem, sammenlignet med en annen restaurant der du bare kan velge fra forhåndsinnstilt måltider. GraphQL er som den første restauranten:
- Få nøyaktig det du ønsker: Med GraphQL kan du be om nøyaktig dataene du trenger, ikke mer, ikke mindre. Tenk deg at du bare vil ha navnet og prisen på en rett, ikke hele listen over ingredienser. Med REST APIer må du få hele rettaldetaljer og ignorere delene du ikke trenger.
- Lag en tilpasset rett: GraphQL API-en vår kan enkelt kombineres for å lage flere tilpassede løsninger, på samme måte som en buffetrestaurant der du kan lage en unik rett nøyaktig slik du trenger det, ved hjelp av ingredienser de allerede har. Derimot er en REST API som et bakeri med forhåndslaget varer pakket i kurver – du kan bare bestille det som allerede er opprettet, og du kan ikke velge å ta med hjem bare delen du vil.
- Mindre ventetid: Siden du kan få all informasjonen du trenger i én forespørsel, er det som å be serveren din om å bringe forrett, hovedrett og dessert alt på en gang, i stedet for å vente mellom retter. De fleste REST APIer krever at du sender flere forespørsler for å få forskjellige informasjonsdeler.
- Enkelt å endre bestillinger: Hvis databehovene til appen din endres, gjør GraphQL det lettere å justere. Du endrer bare spørringen for det du trenger. Med REST, kan det hende du må vente på at kjøkkenet (backend) skal lage en ny rett (endepunkt) for menyen, noe som tar mer tid.
GraphQL tilbyr større fleksibilitet, effektivitet og enkelhet for datahenting enn REST APIer, spesielt når dine behov endres eller vokser.
Hvordan Zonos bruker GraphQL
Under moderniseringen av plattformen vår de siste par årene, har Zonos valgt å bygge ny funksjonalitet ved hjelp av GraphQL for API-en vår i stedet for REST. Vi bestemte oss for å gjøre dette fordi dataene våre er komplekse og sammenkoblede, omtrent som dataene som førte til at Facebook opprettet GraphQL. Denne kompleksiteten gjør det utfordrende å bygge skalerbare REST APIer fordi måtene som utviklere trenger for å hente og bruke dataene på varierer drastisk mellom implementeringene, og REST er ikke fleksibel.
GraphQL løser dette problemet elegantly ved å tillate utviklere som implementerer API-en vår å plukke og velge nøyaktig hvilke data de vil ha og hvordan de får dem. Dette tillater dem å passe det inn i arbeidsflytene sine uten at Zonos trenger å gjøre egendefinert arbeid (mens de venter) for hver situasjon.
Det kombinerte resultatet av å bruke GraphQL og moderniseringene i plattformen vår har gjort API-en vår mer ytelseskraftig, gjort det raskere å integrere Zonos inn i systemene dine, og gjort det mulig for Zonos å levere nye funksjoner raskere.
Bedre funksjoner
Zonos utvikler kontinuerlig nye funksjoner, og GraphQL er den første (og vanligvis den eneste) som mottar disse oppdateringene. Derimot anses REST APIene våre som utdaterte og kan ikke få tilgang til mange av de nye funksjonene våre.
Eksempler på funksjoner begrenset til GraphQL:
- Inkludert prising
- Labels API
- Ny Checkout og Hello
- Eskelstørrelser i API-respons
- Instrumentpanelrapportering
- Mulighet til å forespørre et DDP-tilbud hvis det er mulig, men fortsatt returnere et DDU-tilbud hvis DDP er utilgjengelig for det landet med det servicenivået
- Detaljert sammenbrudd av tolls-, avgifts- og gebyrer (varenivåinformasjon, spesifikke gebyrer) – Instrumentpanelet drives av GraphQL og viser disse dataene for alle butikker, men REST API-responsen inkluderer ikke dette detaljnivået
- Testmodus (kommer snart)
Hvorfor GraphQL
Oppdag hvorfor vi anbefaler å integrere via GraphQL fremfor REST.
Hos Zonos tilbyr vi to hovedtyper APIer for integrering: GraphQL og REST. Selv om REST APIer har vært rundt lenger og kan være mer kjent for mange, har vi gått over til GraphQL for å tillate større fleksibilitet og raskere innovasjon. Selv om begge fortsatt støttes, forklarer denne veiledningen hvorfor GraphQL ikke bare er fremtiden for integreringene våre, men også fremtiden for integreringer generelt og et mer kraftig verktøy for å møte dine behov i dag.