Det kan vara svårt att välja vilken teknik som ska ingå i nästa projekt. I många fall – och särskilt när det gäller att välja mellan GraphQL och RESTful API:er – handlar det om att välja den näst bästa API-designarkitekturen.
Det finns fyra viktiga sätt att bygga API:er: SOAP, GRPC, REST och GraphQL. Vi begränsar oss ofta till REST och GraphQL när vi vill bygga API:er. Detta beror på att REST förändrade de traditionella sätten att bygga API:er med SOAP och GRPC.
GraphQL är ofta betecknat som ett bättre REST eftersom det representerar ett bättre sätt att bygga API:er. Många utvecklare tror att GraphQL kommer att ersätta REST, de har nämligen upptäckt att GraphQL hjälper till att lösa några vanliga utmaningar som utvecklare möter när de bygger REST-API:er.
Dessa två metoder för att bygga API:er är helt olika. I praktiken fungerar dessa tekniker genom att det skickas en HTTP-förfrågan och tas emot ett resultat. De har båda sina för- och nackdelar, och i den här artikeln kommer vi att ha en ingående diskussion om dessa två fantastiska tekniker som har förändrat vårt sätt att utveckla och skala API:er.
Innan vi dyker in i detaljerna ska vi dock först utforska innebörden av GraphQL och RESTful API:er.
Vad är GraphQL?
GraphQL är ett språk för API-förfrågningar samt en körtid för att besvara dessa förfrågningar med befintliga data. Det är även utrustat med kraftfulla verktyg för att även kunna hantera de mest komplexa frågorna.
GraphQL:s centrala funktion är dess förmåga att begära och endast ta emot de specifika data som begärs – inget mer. Detta gör det mycket enklare att skala dina API:er tillsammans med din app.
Den mest spännande delen av GraphQL är dess förmåga att ge dig all data i en enda slutpunkt.
Ovanstående diagram är en typisk representation av GraphQL-arkitekturen. Klienter gör förfrågningar från olika enheter och GraphQL hanterar deras förfrågningar och returnerar endast de begärda uppgifterna. Detta löser problemet med överhämtning och underhämtning i RESTful API:er.
I exemplet ovan visar vi en GraphQL-lekplats och hur du kan fråga efter data med en enda slutpunkt. Överst är API-slutpunkten, till vänster är den förfrågan som begär namn på kontinenter, och sist, till höger, svarar vi på vår förfrågan.
GraphQL skapades av Facebook med det primära syftet att lösa deras mobilapputvecklares upplevelse när de arbetar med REST API:er. Efter att den första versionen med öppen källkod släpptes år 2015 har GraphQL upplevt en enorm tillväxt tack vare att tekniken har antagits av stora aktörer inom teknikbranschen.
Företag som använder GraphQL
Nedan finns en lista över några av de företag och applikationer som använder GraphQL aktivt på sina servrar.
Facebook skapade GraphQL och har använt den i produktion för att driva sina mobilappar sedan år 2012. Det sociala nätverksföretaget, som omsätter flera miljarder dollar, öppnade GraphQL-specifikationen år 2015, vilket gjorde den tillgänglig i många miljöer och för team av alla storlekar.
GitHub
GitHub tillkännager även användningen av GraphQL genom att tillhandahålla ett GraphQL API för att skapa integreringar, hämta data och automatisera dina arbetsflöden med GitHub GraphQL API. GitHub GraphQL API erbjuder mer exakta och flexibla frågor än GitHub REST API.
Pinterest är också en tidig användare av GraphQL. Fotodelningsjätten har offentligt diskuterat sin tidiga utforskning av GraphQL och hur de använder GraphQL-tekniken som driver deras miljardföretag.
Många andra miljardföretag som Intuit, Shopify, Coursera och Airbnb driver sina applikationer med GraphQL. Och denna omfattande preferens för REST fortsätter att växa hela tiden.
Vad är RESTful API?
REST står för ”Representational State Transfer”, vilket är en mjukvaruarkitekturstil för distribuerade hypermediasystem. Den definierar principer och begränsningar för utbyte av resurser mellan servern och klienterna.
Om dessa principer följs i ett API kallas API-tillämpningen för ”RESTful” WordPress REST API är ett utmärkt exempel på detta.
Nedan följer några av de principer och begränsningar som ett API måste uppfylla för att kunna kallas Restful API:
- Frånkoppling av klient-server: Klienterna (frontend) och servern (backend) är helt åtskilda och kan endast kommunicera via slutpunkterna.
- Identiska gränssnitt: Data som syns i gränssnittet är identiska på alla enheter.
- Statuslöshet: Servern kommer inte ihåg om det aktuella begärandet görs för första gången eller inte. Varje gång som en begäran görs måste den innehålla all information som krävs för att behandla den från början.
- Möjlighet att välja bort cachelagring: Cachelagring och lagring av sessioner är tillåtna, men de måste konfigureras så att slutanvändarna kan välja bort cachelagring av data.
- Systemarkitektur i lager: API:er måste utformas så att varken klienten eller servern kan avgöra om de kommunicerar direkt eller via en mellanhand.
Diagrammet nedan visar den grundläggande REST-arkitekturen. Den visar hur förfrågningar och svar vanligtvis hanteras.
Fördelar med GraphQL
Nedan finns några fördelar med att använda GraphQL, som illustrerar varför det är mer än tillräckligt för att bygga nästa miljarddollarsapp.
Hämtning av data via en enda API-slutpunkt
Den främsta fördelen med GraphQL är dess förmåga att få tillgång till alla eller några datapunkter via en enda API-slutpunkt.
Ett av de vanligaste problemen med RESTful API:er är att man har för många slutpunkter för att få tillgång till information. I GraphQL har du bara en enda slutpunkt, så du behöver inte skicka flera förfrågningar för att hämta olika information om ett objekt.
I diagrammet nedan visas ett tydligt exempel på en hämtning av resurser med hjälp av RESTful API och GraphQL. Du kan se att det bara finns en slutpunkt för att få tillgång till resursen i GraphQL-servern, medan det krävs flera API-slutpunkter för att få tillgång till olika resurser i RESTful API.
Ingen över- eller underhämtning
Problemet med över- eller underhämtning är ett känt problem med RESTful API:er. Detta innebär att klienter hämtar data genom att träffa slutpunkter som returnerar fasta datastrukturer, eller när de hämtar antingen mer eller mindre än vad de förväntade sig.
Överhämtning resulterar i att begärandet tar emot – eller ”hämtar” – mer data än vad som krävs för en viss begäran. Tänk dig att du hämtar alla användare i en tabell för att visa deras användarnamn på din hemsida. I det fallet kommer överhämtning att ge alla uppgifter om varje användare, inklusive (men inte bara) namnet.
Underhämtning är relativt sällsynt, men det inträffar när den specifika slutpunkten inte kan tillhandahålla all begärd information. Klienten måste göra ytterligare förfrågningar för att få tillgång till den övriga informationen vid behov.
GraphQL löser effektivt problemet med överhämtning eller underhämtning genom att hämta exakt den resurs som klienten har begärt utan några extra detaljer.
Bättre hantering av komplexa system och mikrotjänster
GraphQL kan förenkla och dölja komplexiteten hos integrerade multi-system.
Säg exempelvis att vi vill migrera från en monolitisk backend-applikation till en mikrotjänstarkitektur. GraphQL API hjälper till att hantera kommunikation mellan olika mikrotjänster genom att slå ihop dem till ett GraphQL-schema.
När dessa scheman väl är definierade kan både frontend och backend kommunicera separat utan några ytterligare ändringar, eftersom frontend vet att data i schemat alltid kommer att vara synkroniserade i hela systemet.
Snabbt och säkert
Problemet med överhämtning kan resultera i en högre bandbreddskonsumtion för klienterna, vilket med tiden kan leda till en fördröjning i din applikation. Att använda RESTful API-designmönster är mer tidskrävande för att sortera ut den information som krävs från en enorm nyttolast.
Tack vare GraphQL:s förmåga att undvika överhämtning och underhämtning returnerar servern en säker, lättläst och förutsägbar form som gör dina API-förfrågningar och svar snabbare.
Fördelar med REST
Trots GraphQL’s växande popularitet är REST fortfarande en av de mest populära API-standarderna. Låt oss ta en titt på varför.
- Inlärningskurva: RESTful API:er är enklast att lära sig och förstå. Detta är den främsta fördelen jämfört med andra API:er.
- Serialisering: REST inkluderar ett flexibelt tillvägagångssätt och format för serialisering av data i JSON.
- Cachelagring: REST API kan hantera en hög belastning med hjälp av en HTTP-proxyserver och cache.
- Komplexa förfrågningar: REST API har en separat slutpunkt för olika förfrågningar, och detta bidrar till att komplexa förfrågningar blir mer hanterbara än i andra API:er
- Rent och enkelt: REST API:er är eleganta, enkla och rena. De är enkla att utforska.
- Standardiserade HTTP-procedurer: REST använder standardiserade HTTP-procedurer för att hämta data och göra förfrågningar.
- Klient/server: Detta innebär att affärslogiken är frikopplad från presentationen. Du kan alltså ändra den ena utan att påverka den andra.
- REST är tillståndslös: Alla meddelanden som utbyts mellan klient och server har all kontext som krävs för att det ska finnas vetskap om vad som ska göras med meddelandet.
Nackdelar med GraphQL
Nu när vi har diskuterat fördelarna med GraphQL kontra REST, låt oss utforska några av GraphQL’s nackdelar:
- Svår inlärningskurva: GraphQL är inte lika enkelt att lära sig som REST. Den mest utmanande delen av byggandet av ett GraphQL API är att utforma schemat. Detta kräver mycket tid och domänkunskap.
- Uppladdning av filer: GraphQL har ingen inbyggd funktion för filuppladdning. Detta kan kringgås genom användning av Base64-kodning, men kostnaden för att koda och avkoda på detta sätt kan vara tidskrävande och dyrt.
- Webbcachelagring: Cachelagring hjälper till att minska den frekventa trafiken till servern, vilket snabbar upp förfrågningarna och svarsprocessen genom att hålla den information som ofta används nära servern. GraphQL stöder eller förlitar sig inte på HTTP-cachelagringsmetoder, utan är istället beroende av Apollo- eller Relay-klienternas cachemekanismer.
- Olämpligt för små tillämpningar: GraphQL är kanske inte den bästa API-arkitekturen för att bygga en liten applikation. Om din applikation inte kräver de mer flexibla frågor som GraphQL erbjuder är REST det bästa alternativet.
- Komplexa frågor: GraphQL’s förmåga att ge en klient exakt vad den vill ha kan även leda till problem med frågeställningar. Om en klient skickar in för många inbäddade frågor kan detta leda till att fel frågor skickas, vilket kan vara mycket tidskrävande för servern. Det är bättre att använda REST med anpassade slutpunkter för att uppfylla sådana förfrågningar.
Nackdelar med REST
Låt oss nu rikta vår uppmärksamhet mot några av REST’s nackdelar:
- Flera rundturer: Det största problemet med REST API:er är att det finns många slutpunkter. Detta innebär att den måste göra otaliga rundresor för att få data, om klienten ska få alla resurser för en komplett applikation.
- Över- och underhämtning: Problemet med över- och underhämtning är en stor nackdel med RESTful APIS. Detta kan leda till att svaren blir långsammare när man hämtar stora oönskade nyttolaster.
- Hierarki: Eftersom REST-API:er bygger på webbadress-refererande resurser passar de dåligt för resurser som inte är naturligt organiserade eller nås i en enkel hierarki.
Varför ska man använda GraphQL i stället för REST?
Vi kommer nu att diskutera varför du kanske vill överväga GraphQL för din framtida API-utveckling i stället för RESTful API.
Starkt typade scheman
GraphQL använder ett starkt typsystem för att definiera API:ets möjligheter. I GraphQL används schema definition language (SDL) för att definiera parametrarna kring hur klienten får tillgång till serverns data. Alla API:er som exponeras för klienten skrivs ner i SDL, vilket löser problemet med den inkonsekvens i datan som man möter i RESTful API:er.
Ingen över- eller underhämtning
Problemet med över- eller underhämtning är ett känt problem med RESTful API:er där klienterna antingen får tillbaka mer eller mindre information än vad de begärde. GraphQL löser detta problem genom att tillhandahålla ett medium där klienten kan specificera den information som behövs och sedan returnera exakt – och endast – den specifika informationen.
Flera slutpunkter
Ett av de största problemen med RESTful API:er är att det finns för många slutpunkter för att få tillgång till information.
Låt oss anta att du vill komma åt en viss användare via dennes ID-nummer. Du skulle få en slutpunkt som /users/1. Men om du vill få tillgång till användarens foton måste du skicka en begäran till en annan slutpunkt, t.ex. /users/1/photos.
I GraphQL har du en enda slutpunkt, och du behöver inte skicka flera förfrågningar för att hämta olika information om användaren.
Jämförelse av GraphQL och REST
Nu ska vi utforska den stora skillnaden mellan GraphQL och RESTful API:er. Därefter ska vi diskutera några av funktionerna i en bra API-design och jämföra hur varje teknik hanterar dem.
Prestanda
Det råder ingen tvekan om att GraphQL presterar snabbare än RESTful API:er tack vare dess förmåga att tillhandahålla en enda slutpunkt för att få tillgång till alla dina resurser. RESTful API:er använder flera slutpunkter, vilket kan leda till nätverksfördröjning.
Komplexitet av frågor
Eftersom slutpunkter inte separeras i flera slutpunkter kan GraphQL-förfrågningar bli alltmer komplexa med tiden. Slutpunkterna för RESTful API:er är å andra sidan separerade, vilket begränsar RESTful API:er till enkla förfrågningar.
Popularitet och stöd från sitt community
GraphQL är ett växande API-arkitekturmönster och förfrågnings-språk. Även om det fortfarande är ungt, växer dess antagandefrekvens och resurspool snabbt, och det finns redan gott om resurser för dem som är intresserade av att lära sig det själva.
REST, å andra sidan, har redan ett stort stöd från sitt community och fortsätter att användas av företag av alla slag, från dem som bygger små mikrotjänster till dem som skapar komplexa sociala appar och mer därtill.
För närvarande är popularitetstävlingen mellan GraphQL och REST oavgjord. Båda teknikerna fortsätter att användas i stor utsträckning och har gott stöd av sina utvecklar-communityn.
Inlärningskurva
Inlärningskurvan för GraphQL är brant. Den kräver en god domänkunskap om API-utveckling och allmän programvaruteknik. En fullständig nybörjare kommer att ha svårt att förstå GraphQL tillräckligt bra för att bygga en komplex applikation.
Omvänt är REST mycket enkelt att komma igång med och kräver mindre domänkunskap från början. RESTful API är väl integrerat i de flesta större programmeringsspråken och populära ramverk, vilket gör det mycket enkelt att lära sig.
Sammanfattning
GraphQL är en ny teknik som följer i spåren av RESTful’s API-arkitekturmönster, precis som REST introducerades för att lösa problem med SOAP API-mönster.
GraphQL ger dig snabbare svar, en enda API-slutpunkt för alla dina frågor och ett strikt schema för en konsekvent dataåtkomst. Detta är anledningen till att mångmiljardföretag har börja byta till GraphQL, även i ett tidigt skede. Men trots sina begränsningar fortsätter GraphQL:s föregångare REST att ha en stark närvaro på scenen.
I den här guiden har vi undersökt allt som du behöver veta om GraphQL och RESTful API:er, inklusive fördelar och nackdelar med varje teknik, för att hjälpa dig att tryggt bestämma vilken du föredrar. Vi har även diskuterat de kända problemen med RESTful API:er – såsom överhämtning, underhämtning och multi-slutpunkter – och hur GraphQL försöker lösa dessa problem och öka prestandan i din app.
Du har nu fått tillräcklig insikt för att kunna välja om GraphQL vs REST är lämpligt för ditt nästa projekt. Låt oss veta i kommentarsfältet vad du kommer att bygga med din valda vinnare!
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
Lämna ett svar