Hva er GraphQL?
GraphQL er en alternativ måte å kommunisere med API-er på, som er svært godt egnet for komplekse datastrukturer og bygging av grensesnitt på toppen av dem. I motsetning til å behandle data som separate, frittstående biter, viser GraphQL hvordan datapunkter henger sammen og relaterer seg til hverandre, noe som gjør det enkelt å be om og motta informasjon.
Tenk på GraphQL som et spørringsspråk som lar deg snakke med API-en som om du snakket direkte med databasen. Ved å bruke GraphQL kan du komme så nært databasen som mulig, slik at du kan velge hva slags data du vil ha og hvordan du får det, noe som gir en massiv ytelsesfordel.
GraphQL ble opprettet av Facebook for å løse problemet med skalering med komplekse datastrukturer. Som et resultat av deres vellykkede adopsjon av det, har flere og flere selskaper begynt å innse fordelene ved å bruke GraphQL for sine API-er.
Allerede kjent med REST? GraphQL vil føles kjent.
GraphQL API-er er enklere å jobbe med enn du kanskje tror. Hvis du er vant til å jobbe med REST API-er, her er hvordan kjernebegrepene fra REST oversettes til GraphQL.
| Funksjon | REST | GraphQL |
|---|---|---|
| Endepunkt | Forespørslene gjøres til flere endepunkter for forskjellige handlinger | Alle forespørslene gjøres til et enkelt endepunkt (f.eks. /graphql) |
| Datainnhenting | Bruk GET metoder på spesifikke endepunkter for å hente data | Bruk forespørsel for å be om nøyaktig de dataene som trengs, noe som reduserer overhenting eller underhenting |
| Datamodifikasjon/handlinger | Bruk HTTP metoder som POST, PUT, PATCH eller DELETE for å endre eller prosessere data. | Bruk mutasjoner for å utføre operasjoner (f.eks. opprette parter, beregne landed kostnader) |
| Svarformat | Faste svarformater returnerer alle forhåndsdefinerte felt, uavhengig av om de er nødvendige | Fleksible svar tillater spesifisering av nøyaktig hvilke felt som skal inkluderes, noe som reduserer unødvendig datatransport (Hvis denne fleksibiliteten føles komplisert, kan du enkelt bruke de forhåndsdefinerte forespørselseksemplene i dokumentasjonen vår for en REST-aktig opplevelse) |
| Datatilkobling | Flere forespørsel er ofte nødvendig for å hente relaterte data | Nestede forespørsel gjør det mulig å hente relaterte data i en enkelt forespørsel (f.eks. partydetaljer og fraktartikler sammen). Brukere kan også bygge arbeidsflyter for å håndtere flere mutasjoner innen en enkelt GraphQL-forespørsel, noe som reduserer kompleksitet og forbedrer effektivitet |
Fordeler med GraphQL
Raskere svar
GraphQL gir raskere svar gjennom presis datainnhenting, bruk av et enkelt endepunkt og forbedrede muligheter for batching og caching.
Presis datainnhenting
En vanlig utfordring med REST er overhenting eller underhenting 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ørsel om nøyaktig det som trengs—ikke mer, ikke mindre. Denne spesifisiteten forbedrer ikke bare ytelsen, men forenkler også prosessen for de som interagerer med API-en, noe som gjør systemet mer effektivt og brukervennlig.
Eksempler på hvordan dette er nyttig:
- Dette lar frontend-utviklere hente nøyaktig de dataene de trenger for sine UI-komponenter, noe som reduserer antall rundreiser til serveren og forbedrer ytelsen.
- Tenk deg at du vil få en HS-kodeklassifisering, kartonisering, fraktvurdering, og landed cost tilbud på varer i en checkout. Hvis du er integrert via GraphQL API, kan du gjøre et enkelt kall med de nødvendige arbeidsflytene for å få alt du trenger (og ingenting du ikke trenger) i et enkelt svar. I kontrast, med REST API-er, måtte du først kalle Classify REST API, deretter kalle Rating REST API separat etterpå, og til slutt plugge den klassifiseringen og fraktvurderingen inn i ditt tredje kall til Landed Cost REST API. Alle disse REST API-ene ville returnere hver bit av informasjon de kan, noe som får deg til å måtte sortere gjennom svaret for dataene du trenger. Denne besparelsen i hastighet har en innvirkning på å returnere en komplett landed cost raskt, før kunden forlater.
Ett endepunkt
GraphQL API-er har vanligvis et enkelt endepunkt, i motsetning til REST API-er som ofte har flere endepunkter for forskjellige ressurser og handlinger. Dette gjør det enklere å administrere og forstå API-en.
Batching og caching
GraphQLs evne til å batche forespørsel og dens støtte for caching-strategier fører til betydelige ytelsesforbedringer. Disse funksjonene reduserer belastningen på nettverk og servere, noe som oversettes til raskere, mer pålitelige interaksjoner for brukerne.
Veldefinerte skjemaer
GraphQL API-er er basert på et sterkt typet skjema. Dette skjemaet definerer strukturen av dataene som er tilgjengelige og operasjonene som kan utføres. Dette gir klarhet om hvilke data som er tilgjengelige og hvordan man får tilgang til dem, noe som kan forbedre utviklerproduktiviteten og redusere feil. For eksempel kan frontend-team utforske grafen for å få nøyaktig det de trenger i stedet for å vente på et nytt REST-endepunkt.
Evne til å forbedre uten å bryte eksisterende klienter
Å legge til nye funksjoner eller endre eksisterende i GraphQL forstyrrer ikke nåværende integrasjoner, takket være dens fleksible spørringsstruktur. Denne evnen sikrer at forbedringer kan gjøres uten å bryte kompatibiliteten med eksisterende klienter.
Oppdatert dokumentasjon
Takket være GraphQLs introspeksjonsfunksjon, genereres og oppdateres dokumentasjonen automatisk med hver endring. Dette sikrer at all informasjon som gis til utviklere er aktuell, noe som reduserer integrasjonsproblemer og supporthenvendelser relatert til utdaterte dokumenter—en utfordring som ofte oppleves med REST API-dokumentasjon.
Gå gjennom 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 akkurat slik du vil ha dem, sammenlignet med en annen restaurant hvor du bare kan velge fra faste måltider. GraphQL er som den første restauranten:
- Få akkurat det du vil ha: Med GraphQL kan du be om akkurat de 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 API-er må du få hele rettens detaljer og ignorere delene du ikke trenger.
- Sammensett en tilpasset rett: Våre GraphQL API-er kan enkelt kombineres for å lage mer tilpassede løsninger, lik en buffet-restaurant hvor du kan lage en unik rett akkurat slik du trenger den, ved å bruke ingredienser de allerede har. I motsetning til dette er et REST API som et bakeri med ferdiglagde varer pakket i kurver—du kan bare bestille det som allerede er laget, og du kan ikke velge å ta med deg bare den delen du vil ha.
- Mindre venting: Siden du kan få all informasjonen du trenger i en enkelt forespørsel, er det som å be servitøren din om å bringe forretten, hovedretten og desserten samtidig, i stedet for å vente mellom rettene. De fleste REST API-er krever at du sender flere forespørsel for å få forskjellige deler av informasjonen.
- Enkelt å endre bestillinger: Hvis databehovene til appen din endres, gjør GraphQL det enklere å justere. Du endrer bare spørringen for det du trenger. Med REST må du kanskje vente på at kjøkkenet (backend) lager et nytt måltid (endepunkt) for menyen, noe som tar mer tid.
GraphQL tilbyr mer fleksibilitet, effektivitet og enkelhet for å hente data enn REST API-er, spesielt etter hvert som behovene dine endres eller vokser.
Hvordan Zonos bruker GraphQL
Mens vi moderniserte plattformen vår de siste par årene, har Zonos valgt å bygge ny funksjonalitet ved å bruke GraphQL for vårt API i stedet for REST. Vi bestemte oss for å gjøre dette fordi dataene våre er komplekse og sammenkoblede, mye lik dataene som førte Facebook til å lage GraphQL. Denne kompleksiteten gjør det utfordrende å bygge skalerbare REST API-er fordi måtene utviklere trenger å hente og bruke dataene på varierer dramatisk mellom implementeringer, og REST er ikke fleksibelt.
GraphQL løser dette problemet på en ryddig måte ved å la utviklere som implementerer vårt API velge nøyaktig hvilke data de vil ha og hvordan de får dem. Dette lar dem tilpasse det til arbeidsflytene sine uten at Zonos trenger å gjøre tilpasset arbeid (mens de venter) for hver situasjon.
Det samlede resultatet av å bruke GraphQL og moderniseringene i plattformen vår har gjort API-en vår mer ytelseseffektiv, gjort integreringen av Zonos i systemene dine raskere, 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 eneste) som mottar disse oppdateringene. I motsetning til dette anses våre REST API-er som utdaterte og kan ikke få tilgang til mange av våre nye funksjoner.
Eksempler på funksjoner som er begrenset til GraphQL:
- Inclusive pricing
- Etikett-API
- Ny Checkout og Hello
- Bokstørrelser i API-respons
- Dashboard-rapportering
- Mulighet til å be om et DDP-tilbud hvis mulig, men fortsatt returnere et DDU-tilbud hvis DDP ikke er tilgjengelig for det landet med det tjenestenivået
- Detaljert oversikt over avgifter, skatter og gebyrer (vare-nivå informasjon, spesifikke gebyrer)—Dashboardet er drevet 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 integrering via GraphQL fremfor REST.
Hos Zonos tilbyr vi to hovedtyper API-er for integrering: GraphQL og REST. Selv om REST API-er har eksistert lenger og kan være mer kjent for mange, har vi gått over til GraphQL for å gi mer fleksibilitet og raskere innovasjon. Selv om begge fortsatt støttes, forklarer denne guiden hvorfor GraphQL ikke bare er fremtiden for våre integrasjoner, men også fremtiden for integrasjoner generelt og et mer kraftfullt verktøy for å møte dine behov i dag.