Det kan være svært at vælge de teknologier, der skal indgå i den tekniske stack i dit næste projekt. I mange tilfælde – og især når det drejer sig om at vælge mellem GraphQL- og RESTful-API’er – handler det om at vælge den næstbedste API-designarkitektur.
Der er fire væsentlige måder at opbygge API’er på: SOAP, GRPC, REST og GraphQL. Vi indsnævrer ofte vores tanker til REST og GraphQL, når vi ønsker at bygge API’er. Det skyldes, at REST ændrede de traditionelle måder at opbygge API’er på med SOAP og GRPC.
GraphQL er omtalt som det meste oplagte REST, fordi det repræsenterer en bedre måde at bygge API’er på. Mange udviklere mener, at GraphQL vil erstatte REST. Mange flere har allerede opdaget, at GraphQL hjælper med at løse nogle almindelige udfordringer, som udviklere står over for, når de bygger REST-API’er.
Disse to metoder til opbygning af API’er er helt forskellige. I praksis fungerer disse teknologier ved at sende en HTTP-forespørgsel og modtage resultatet. De har begge deres fordele og ulemper, og i denne artikel vil vi udførligt diskutere disse to fantastiske teknologier, som har ændret den måde, vi udvikler og skalerer API’er på.
Inden vi dykker ned i detaljerne, skal vi dog først undersøge betydningen af GraphQL og RESTful API’er.
Hvad er GraphQL?
GraphQL er et API-forespørgselssprog samt en runtime til at besvare disse forespørgsler med eksisterende data. Det er også udstyret med kraftfulde værktøjer til at håndtere selv de mest komplekse forespørgsler.
GraphQL’s centrale funktion er dets evne til kun at anmode om og modtage de specifikke data, der anmodes om – intet andet. Dette gør det meget enklere at skalere dine API’er sammen med din app.
Den mest spændende del af GraphQL er dens evne til at give dig alle data i ét endpoint.
Ovenstående diagram er en typisk repræsentation af GraphQL-arkitekturen. Klienter foretager forespørgsler fra forskellige enheder, og GraphQL håndterer deres forespørgsler og returnerer kun de ønskede data. Dette løser pænt problemet med over- og under-fetching i RESTful API’er.
I ovenstående eksempel viser vi en GraphQL-legeplads, og hvordan du kan forespørge efter data med et enkelt endpoint. Øverst er API-endpunktet, til venstre er forespørgslen, der anmoder om navne på kontinenter, og til sidst, til højre, svarer vi på den forespørgsel, vi anmodede om.
GraphQL blev skabt af Facebook med det primære formål at løse deres mobile app-udvikleres oplevelse, når de arbejder med REST API’er. Siden den første open source-version blev frigivet i 2015, har GraphQL oplevet en enorm vækst på grund af, at teknologien er blevet taget i brug af store spillere i teknologibranchen.
Virksomheder, der bruger GraphQL
Nedenfor er der en liste over blot nogle af de virksomheder og applikationer, der bruger GraphQL aktivt på deres servere.
Facebook har skabt GraphQL, og de har brugt det i produktion til at drive deres mobilapps siden 2012. Den milliardstore virksomhed, der driver sociale netværk, åbnede GraphQL-specifikationen i 2015, hvilket gjorde den tilgængelig på tværs af mange miljøer og for teams af alle størrelser.
GitHub
GitHub annoncerer også brugen af GraphQL ved at stille et GraphQL API til rådighed for oprettelse af integrationer, hentning af data og automatisering af dine arbejdsgange ved hjælp af GitHub GraphQL API’en. GitHub GraphQL API tilbyder mere præcise og fleksible forespørgsler end GitHub REST API’et.
Pinterest er også en tidlig bruger af GraphQL. Fotodelingskæmpen har offentligt diskuteret deres tidlige udforskning af GraphQL og hvordan de bruger GraphQL-teknologien, der driver deres milliarddyre virksomhed.
Mange andre milliardvirksomheder som Intuit, Shopify, Coursera og Airbnb driver deres applikationer med GraphQL. Og denne vidtrækkende præference for REST fortsætter kun med at vokse.
Hvad er RESTful API?
REST står for “Representational State Transfer”, som er en softwarearkitekturstil for distribuerede hypermediesystemer. Den definerer principper og begrænsninger for udveksling af ressourcer mellem serveren og klienterne.
Hvis disse principper følges i et API, betegnes API’ets anvendelse som “RESTful” WordPress REST API er et godt eksempel herpå.
Nedenfor er nogle af de principper og begrænsninger, som et API skal opfylde for at blive omtalt som et Restful API:
- Afkobling af klient-server: Klienterne (frontend) og serveren (backend) er helt adskilte og kan kun kommunikere via endpoints.
- Ensartet grænseflade: Data, der ses i grænsefladen, er identiske på tværs af alle enheder.
- Statelessness: Serveren husker ikke, om den aktuelle forespørgsel er første gang eller ej. Hver gang en anmodning fremsættes, skal den indeholde alle de oplysninger, der er nødvendige for at behandle den fra bunden.
- Cachelagring: Caching og sessionsopbevaring er tilladt, men de skal være konfigureret således, at slutbrugerne kan fravælge caching af data.
- Systemarkitektur i flere lag: API’er skal være udformet således, at hverken klienten eller serveren kan se, om de kommunikerer direkte eller gennem en mellemmand.
Nedenstående diagram viser den grundlæggende REST-arkitektur. Det viser, hvordan anmodninger og svar typisk håndteres.
GraphQL vs REST: Hvad er forskellen?
Fordele ved GraphQL
Nedenfor er der et par fordele ved at bruge GraphQL, som illustrerer, hvorfor det er mere end tilstrækkeligt til at bygge den næste milliarddollar-app.
Hentning af data gennem et enkelt API-endpoint
Den største fordel ved GraphQL er dens evne til at få adgang til alle eller alle datapunkter gennem et enkelt API-endpoint.
Et af de mest almindelige problemer med RESTful API’er er at have for mange endpoints til at få adgang til oplysninger. I GraphQL har du kun et enkelt endpoint, så du behøver ikke at sende flere anmodninger for at hente forskellige oplysninger om et objekt.
Diagrammet nedenfor viser et tydeligt eksempel på hentning af ressourcer ved hjælp af RESTful API og GraphQL. Du kan se, at der kun er ét slutpunkt for at få adgang til ressourcen i GraphQL-serveren, mens der er brug for flere API-endpoints for at få adgang til forskellige ressourcer i RESTful API’et.
Ingen over- eller under-fetching
Problemet med over- eller under-fetching er et kendt problem med RESTful API’er. Dette er, når klienter henter data ved at ramme endpoints, der returnerer faste datastrukturer, eller de henter enten mere eller mindre end det, de forventede.
Over-fetching resulterer i, at anmodningen modtager – eller “henter” – flere data, end hvad der kræves af en given anmodning. Forestil dig, at du henter alle brugere i en tabel med henblik på at vise deres brugernavne på din hjemmeside. I det tilfælde vil over-fetching returnere alle data om hver bruger, herunder (men ikke kun) navnet.
Under-fetching er forholdsvis sjældent, men det sker, når det specifikke endpoint ikke kan levere alle de ønskede oplysninger. Klienten skal foretage yderligere anmodninger for at få adgang til de andre oplysninger efter behov.
GraphQL løser effektivt problemet med over- eller under-fetching ved at hente præcis den ressource, som klienten har anmodet om, uden ekstra detaljer.
Bedre håndtering af komplekse systemer og mikrotjenester
GraphQL kan forene og skjule kompleksiteten af integrerede flere systemer.
Lad os f.eks. sige, at vi ønsker at migrere fra en monolitisk backend-applikation til en mikroservice-arkitektur. GraphQL API’et hjælper med at håndtere kommunikation mellem forskellige microservices ved at slå dem sammen i ét GraphQL-skema.
Når disse skemaer er defineret, kan både frontend og backend kommunikere separat uden yderligere ændringer, da frontend’en ved, at dataene i skemaet altid vil være synkroniseret på tværs af systemet.
Hurtig og sikker
Problemet med over-fetching kan resultere i et højere båndbreddeforbrug for klienterne, hvilket med tiden kan medføre forsinkelse i din applikation. Brug af RESTful API-designmønstre er mere tidskrævende for at sortere de nødvendige oplysninger fra en enorm payload.
På grund af GraphQL’s evne til at undgå over- og under-fetching returnerer serveren en sikker, letlæselig og forudsigelig form, hvilket gør dine API-forespørgsler og -svar hurtigere.
Fordele ved REST
På trods af GraphQL’s stigende popularitet er REST stadig en af de mest populære API-standarder. Lad os tage et kig på hvorfor.
- Indlæringskurve: RESTful API’er er nemmest at lære og forstå. Dette er den primære fordel i forhold til andre API’er.
- Serialisering: REST leveres med en fleksibel tilgang og formater til serialisering af data i JSON.
- Caching: REST API kan håndtere en høj belastning ved hjælp af en HTTP-proxyserver og cache.
- Kompleks anmodning: REST API’er har et separat endpoint til forskellige anmodninger, og det er med til at gøre den komplekse anmodning mere håndterbar end i andre API’er
- Ren og enkel: REST API’er er elegante, enkle og rene. De er ukomplicerede at udforske.
- Standard HTTP-procedurer: REST anvender standard HTTP-procedurekald til at hente data og foretage anmodninger.
- Klient/server: Det betyder, at dens forretningslogik er afkoblet fra præsentationen. Så du kan ændre den ene uden at påvirke den anden.
- REST er stateless: Alle de meddelelser, der udveksles mellem klient og server, har al den kontekst, der er nødvendig for at vide, hvad der skal ske med meddelelsen.
Ulemper ved GraphQL
Nu hvor vi har diskuteret fordelene ved GraphQL vs. REST, lad os undersøge nogle af GraphQL’s ulemper:
- Svær indlæringskurve: GraphQL er ikke så let at lære som REST. Den mest udfordrende del af opbygningen af et GraphQL API er at designe skemaet. Dette kræver meget tid og domæneviden.
- Upload af filer: GraphQL har ikke en indbygget filopload-funktion. Dette kan omgås ved hjælp af Base64-kodning, men omkostningerne ved at kode og afkode på denne måde kan være tidskrævende og dyre.
- Web Caching: Caching hjælper med at reducere hyppig trafik til serveren, hvilket fremskynder forespørgsler og svarprocessen ved at holde ofte tilgåede oplysninger tæt på serveren. GraphQL understøtter eller er ikke afhængig af HTTP-cachingmetoder og er i stedet afhængig af Apollo- eller Relay-klienternes cachingmekanismer.
- Uegnet til små applikationer: GraphQL er muligvis ikke den bedste API-arkitektur til opbygning af en lille applikation. Hvis din app ikke kræver de mere fleksible forespørgsler, som GraphQL tilbyder, er REST den rette løsning.
- Komplekse forespørgselsproblemer: GraphQL’s evne til at give en klient præcis det, den ønsker, kan også føre til problemer med spredning af forespørgsler. Hvis en klient indsender for mange indlejrede forespørgsler, kan det føre til, at de forkerte forespørgsler bliver sendt, hvilket kan være meget tidskrævende for serveren. Det er bedre at anvende REST med brugerdefinerede endpoints til at imødekomme sådanne forespørgsler.
Ulemper ved REST
Lad os nu vende vores opmærksomhed mod nogle af REST’s ulemper:
- Flere rundrejser: Det største problem med REST API’er er karakteren af mange endpoints. Det betyder, at for at klienten kan få alle ressourcerne til en komplet applikation, skal den foretage utallige rundrejser for at få dataene.
- Over-fetching og under-fetching: Problemet med over- og under-fetching er en stor ulempe ved RESTful APIS. Det kan medføre forsinkelser i svarene på grund af hentning af store uønskede nyttelaster.
- Hierarki: Da REST-API’er er bygget på URI-refererende ressourcer, passer de dårligt til ressourcer, der ikke naturligt er organiseret eller tilgås i et simpelt hierarki.
Hvorfor bruge GraphQL i stedet for REST?
Herefter vil vi diskutere, hvorfor du måske bør overveje GraphQL til din fremtidige API-udvikling i stedet for RESTful API.
Stærkt typet schema
GraphQL bruger et stærkt typesystem til at definere API’ets muligheder. I GraphQL bruges schema definitionssprog (SDL) til at definere parametrene omkring, hvordan klienten får adgang til serverens data. Alle API’er, der udsættes for klienten, er nedskrevet i SDL, hvilket løser problemet med datainkonsistens, der ses i RESTful API’er.
Ingen over- eller underhentning
Problemet med over- eller under-fetching er et kendt problem med RESTful API’er, hvor klienterne får enten flere eller færre oplysninger tilbage, end de har anmodet om. GraphQL løser dette problem ved at give klienten mulighed for at angive de nødvendige oplysninger og derefter returnere præcis – og kun – de specifikke oplysninger.
Flere endepunkter
Et af de største problemer ved RESTful API’er er at have for mange endpoints til at få adgang til oplysninger.
Lad os antage, at du ønsker at få adgang til en bestemt bruger via dennes ID-nummer. Du ville blive præsenteret for et endpoint som /users/1. Men hvis du vil have adgang til den pågældende brugers billeder, skal du sende en anmodning til et andet slutpunkt, f.eks. /users/1/photos.
I GraphQL har du et enkelt slutpunkt, og du behøver ikke at sende flere anmodninger for at hente forskellige oplysninger om brugeren.
GraphQL vs. REST-opgør
Til sidst vil vi undersøge den største forskel mellem GraphQL og RESTful API’er. Derefter vil vi diskutere nogle af funktionerne i et godt API-design og sammenligne, hvordan de enkelte teknologier håndterer dem.
Ydeevne
Der er ingen tvivl om, at GraphQL performer hurtigere end RESTful API’er på grund af dets evne til at levere et enkelt endpoint til at få adgang til alle dine ressourcer. RESTful API’er bruger flere endpoints, hvilket kan resultere i netværkslatenstid.
Forespørgselskompleksitet
Da endpoints ikke er adskilt i flere endpoints, kan GraphQL-forespørgsler blive stadig mere komplekse med tiden. RESTful API endpoints er på den anden side adskilt, hvilket begrænser RESTful API’er til enkle forespørgsler.
Popularitet og fællesskabsstøtte
GraphQL er et voksende API-arkitekturmønster og forespørgselssprog. Selv om det stadig er ungt, vokser dets udbredelsesgrad og ressourcepulje hurtigt, og der er allerede masser af ressourcer til dem, der er interesserede i at lære det selv.
REST kan på den anden side allerede prale af stor fællesskabsstøtte og anvendes fortsat af virksomheder af alle slags, lige fra dem, der bygger små mikrotjenester, til dem, der skaber komplekse sociale apps og videre.
På nuværende tidspunkt er popularitetskonkurrencen mellem GraphQL vs. REST uafgjort. Begge teknologier er fortsat meget udbredt og godt støttet af udviklingsmiljøet.
Indlæringskurve
Indlæringskurven for GraphQL er stejl. Det kræver god domæneviden om API-udvikling og generel softwareudvikling. En komplet nybegynder vil have svært ved at forstå GraphQL godt nok til at bygge en kompleks applikation.
Omvendt er REST meget let at komme i gang med og kræver mindre domæneviden fra starten. RESTful API er godt integreret i de fleste større programmeringssprog og populære frameworks, hvilket gør det meget nemt at lære det.
Opsummering
GraphQL er en ny teknologi, der følger i sporene af RESTful API-arkitekturmønstre, ligesom REST blev introduceret for at løse problemer med SOAP API-mønstre.
GraphQL giver dig hurtigere svar, et enkelt API-endpoint til alle dine forespørgsler og et stricht schemafor konsistent dataadgang. Disse grunde er det, der har fået milliardvirksomheder til at begynde at skifte til GraphQL, selv i den tidlige fase. På trods af sine begrænsninger er GraphQL’s stamfader REST dog fortsat stærkt repræsenteret på scenen.
I denne guide har vi undersøgt alt, hvad du behøver at vide om GraphQL og RESTful API’er, herunder fordele og ulemper ved hver teknologi, så du med sikkerhed kan beslutte, hvilken teknologi du foretrækker. Vi har også diskuteret de kendte problemer med RESTful API’er – såsom over-fetching, under-fetching og flere endpoints – og hvordan GraphQL forsøger at løse disse problemer og øge din app’s ydeevne.
Du har nu fået nok indsigt til at vælge, om GraphQL vs. REST er passende for dit næste projekt. Lad os vide i kommentarfeltet, hvad du vil bygge med din valgte vinder!
I am a Software Engineer and Content Creator who is geared toward building high-performing and innovative products following best practices and industry standards. I also love writing about it at Masteringbackend.com. Follow me on Twitter, LinkedIn, and About Me
Den største forskel er, hvordan de kommunikerer med serveren. GraphQL er en nyere teknologi, der bruger et enkelt endpoint til at svare på forespørgsler, mens REST bruger et sæt endpoints, der reagerer på specifikke HTTP-anmodninger. GraphQL anses generelt for at være mere effektiv og fleksibel end REST.