Vad är GraphQL?
GraphQL är ett alternativt sätt att kommunicera med API:er som är mycket lämpligt för komplexa datakonstruktioner och att bygga gränssnitt ovanpå dem. Till skillnad från att behandla data som separata, fristående bitar, visar GraphQL hur databitarnas kopplingar och relationer till varandra ser ut, vilket gör det enkelt att begära och ta emot information.
Tänk på GraphQL som ett frågespråk som låter dig prata med API:et som om du pratade direkt med databasen. Genom att använda GraphQL kan du komma så nära databasen som möjligt, vilket låter dig välja och välja vilken data du vill ha och hur du får den, vilket ger en enorm prestandafördel.
GraphQL skapades av Facebook för att lösa problemet med skalning med komplexa datakonstruktioner. Som ett resultat av deras framgångsrika adoption av det har fler och fler företag börjat inse fördelarna med att använda GraphQL för sina API:er.
Nyckelskillnader från REST
GraphQL API:er är lättare att arbeta med än du kanske tror. Om du är van vid att arbeta med REST API:er, här är de grundläggande skillnaderna att ha i åtanke:
| Funktion | REST | GraphQL |
|---|---|---|
| Endpoint | Förfrågningar görs till flera endpoints för olika åtgärder | Alla förfrågningar görs till en enda endpoint (t.ex. /graphql) |
| Datahämtning | Använd GET-metoder på specifika endpoints för att hämta data | Använd frågor för att begära exakt den data som behövs, vilket minskar över- eller underhämtning |
| Datamodifiering/åtgärder | Använd HTTP-metoder som POST, PUT, PATCH eller DELETE för att modifiera eller bearbeta data. | Använd mutationer för att utföra operationer (t.ex. skapa parter, beräkna landed costs) |
| Svarsformat | Fasta svarsformat returnerar alla fördefinierade fält, oavsett om de behövs eller inte | Flexibla svar tillåter att specificera exakt vilka fält som ska inkluderas, vilket minskar onödig datatransfer |
| Datakoppling | Flera förfrågningar krävs ofta för att hämta relaterad data | Nästa frågor möjliggör hämtning av relaterad data i en enda förfrågan (t.ex. partdetaljer och fraktartiklar tillsammans). Användare kan också bygga arbetsflöden för att hantera flera mutationer inom en enda GraphQL-förfrågan, vilket minskar komplexiteten och förbättrar effektiviteten |
Fördelar med GraphQL
Snabbare svar
GraphQL ger snabbare svar genom exakt datahämtning, användning av en enda endpoint och förbättrade möjligheter för batching och caching.
Exakt datahämtning
En vanlig utmaning med REST är över- eller underhämtning av data—antingen att få för mycket onödig information eller inte tillräckligt med det som behövs på en gång. GraphQL eliminerar detta genom att tillåta förfrågningar för exakt vad som behövs—inget mer, inget mindre. Denna specificitet förbättrar inte bara prestanda utan förenklar också processen för dem som interagerar med API:et, vilket gör systemet mer effektivt och användarvänligt.
Exempel på hur detta är användbart:
- Detta gör att frontendutvecklare kan hämta exakt den data de behöver för sina UI-komponenter, vilket minskar antalet rundresor till servern och förbättrar prestanda.
- Tänk dig att du vill få en HS-kodklassificering, kartläggning, fraktvärdering och landed cost offert på artiklar i en checkout. Om du är integrerad via GraphQL API kan du göra ett enda samtal med de nödvändiga arbetsflödena för att få allt du behöver (och inget du inte behöver) i ett enda svar. I kontrast, med REST API:er, skulle du först behöva anropa Classify REST API, sedan anropa Rating REST API separat efteråt, och slutligen koppla den klassificeringen och fraktvärderingen till ditt tredje samtal till Landed Cost REST API. Alla dessa REST API:er skulle returnera varje bit information som de kan, vilket gör att du måste gå igenom svaret för att hitta den data du behöver. Denna tidsbesparing gör en skillnad i att snabbt returnera en komplett landed cost innan köparen lämnar.
En enda endpoint
GraphQL API:er har vanligtvis en enda endpoint, till skillnad från REST API:er som ofta har flera endpoints för olika resurser och åtgärder. Detta gör det enklare att hantera och förstå API:et.
Batching och caching
GraphQL:s förmåga att batcha frågor och dess stöd för cachingstrategier leder till betydande prestandaförbättringar. Dessa funktioner minskar belastningen på nätverk och servrar, vilket översätts till snabbare, mer pålitliga interaktioner för användare.
Väl definierade scheman
GraphQL API:er baseras på ett starkt typat schema. Detta schema definierar strukturen för den tillgängliga datan och de operationer som kan utföras. Detta ger tydlighet om vilken data som är tillgänglig och hur man får åtkomst till den, vilket kan förbättra utvecklarproduktiviteten och minska fel. Till exempel kan frontendteam utforska grafen för att få exakt vad de behöver istället för att vänta på en ny REST-endpoint.
Förmåga att förbättra utan att bryta befintliga klienter
Att lägga till nya funktioner eller modifiera befintliga i GraphQL stör inte aktuella integrationer, tack vare dess flexibla frågestruktur. Denna kapabilitet säkerställer att förbättringar kan göras utan att bryta kompatibiliteten med befintliga klienter.
Uppdaterad dokumentation
Tack vare GraphQL:s introspektionsfunktion genereras och uppdateras dokumentationen automatiskt med varje förändring. Detta säkerställer att all information som ges till utvecklare är aktuell, vilket minskar integrationsproblem och supportärenden relaterade till föråldrad dokumentation—en utmaning som ofta möts med REST API-dokumentation.
Granska vår GraphQL-dokumentation och vår REST-dokumentation för att se skillnaden.
En analogi
Föreställ dig att du är på en restaurang med en meny som låter dig beställa rätter precis som du vill ha dem, jämfört med en annan restaurang där du bara kan välja från fasta måltider. GraphQL är som den första restaurangen:
- Få exakt vad du vill ha: Med GraphQL kan du be om exakt de data du behöver, varken mer eller mindre. Tänk dig att du bara vill ha namnet och priset på en rätt, inte hela listan över ingredienser. Med REST API:er måste du få hela rätternas detaljer och ignorera de delar du inte behöver.
- Sammansätt en anpassad rätt: Våra GraphQL API:er kan enkelt kombineras för att skapa mer anpassade lösningar, liknande en bufférestaurang där du kan skapa en unik rätt precis som du behöver den, med ingredienser de redan har. I kontrast är ett REST API som ett bageri med färdiga varor paketerade i korgar—du kan bara beställa det som redan har skapats och du kan inte välja att ta hem bara den bit du vill ha.
- Mindre väntan: Eftersom du kan få all information du behöver i en enda begäran, är det som att be din servitör att ta med din förrätt, huvudrätt och dessert på en gång, istället för att vänta mellan rätterna. De flesta REST API:er kräver att du skickar flera begärningar för att få olika delar av informationen.
- Enkelt att ändra beställningar: Om din apps databehov förändras gör GraphQL det enklare att justera. Du ändrar bara frågan för vad du behöver. Med REST kan du behöva vänta på att köket (backend) ska skapa en ny måltid (endpoint) för menyn, vilket tar mer tid.
GraphQL erbjuder mer flexibilitet, effektivitet och enkelhet för att hämta data än REST API:er, särskilt när dina behov förändras eller växer.
Hur Zonos använder GraphQL
Under moderniseringen av vår plattform under de senaste åren har Zonos valt att bygga ny funktionalitet med GraphQL för vår API istället för REST. Vi beslutade att göra detta eftersom våra data är komplexa och sammanlänkade, mycket likt de data som ledde Facebook till att skapa GraphQL. Denna komplexitet gör det utmanande att bygga skalbara REST API:er eftersom sätten som utvecklare behöver hämta och använda data varierar dramatiskt mellan implementationer, och REST är inte flexibelt.
GraphQL löser detta problem på ett snyggt sätt genom att låta utvecklare som implementerar vår API välja exakt vilka data de vill ha och hur de får dem. Detta gör att de kan passa in det i sina arbetsflöden utan att Zonos behöver göra anpassat arbete (medan de väntar) för varje situation.
Det sammansatta resultatet av att använda GraphQL och moderniseringarna i vår plattform har gjort vår API mer prestanda, gjort integrationen av Zonos i dina system snabbare, och gjort det möjligt för Zonos att leverera nya funktioner snabbare.
Bättre funktioner
Zonos utvecklar kontinuerligt nya funktioner, och GraphQL är den första (och vanligtvis enda) som får dessa uppdateringar. I kontrast anses våra REST API:er vara i slutet av sin livscykel och kan inte få tillgång till många av våra nya funktioner.
Exempel på funktioner som är begränsade till GraphQL:
- Inclusive pricing
- Etikett-API
- Ny Checkout och Hello
- Boxstorlekar i API-svaret
- Dashboard-rapportering
- Möjlighet att begära en DDP-offert om möjligt, men fortfarande returnera en DDU-offert om DDP inte är tillgänglig för det landet med den tjänstenivån
- Detaljerad uppdelning av avgifter, skatter och avgifter (artikel-nivå information, specifika avgifter)—Dashboard drivs av GraphQL och visar dessa data för alla butiker, men REST API-svaret inkluderar inte denna detaljnivå
- Testläge (kommer snart)
Varför GraphQL
Upptäck varför vi rekommenderar att integrera via GraphQL istället för REST.
På Zonos erbjuder vi två huvudtyper av API:er för integration: GraphQL och REST. Medan REST API:er har funnits längre och kan vara mer bekanta för många, har vi övergått till GraphQL för att möjliggöra mer flexibilitet och snabbare innovation. Även om båda fortfarande stöds, förklarar denna guide varför GraphQL inte bara är framtiden för våra integrationer utan också framtiden för integrationer i allmänhet och ett kraftfullare verktyg för att möta dina behov idag.