När du behöver bygga ett API kommer ditt sinne sannolikt att hoppa till VILA, den de facto standard för API-skapande. Detta förändras dock med ökningen av GraphQL popularitet.
Inte alla förstår helt vad GraphQL handlar om eller varför det förklaras efterträdaren till REST. Det är precis vad jag kommer att klargöra i den här artikeln. Här kommer jag att visa upp GraphQL: s huvudfunktioner och fördelar jämfört med REST, vilket belyser några punkter där båda skiljer sig åt.
Målet är att ge en kort förklaring till alla som fortfarande inte har lärt känna GraphQL, klargöra vad det gör bättre än REST för de som fortfarande är skeptiska till denna teknik, och i vilka fall vi ska använda GraphQL eller REST.
GraphQL är en frågespråk för API:er som möjliggör deklarativ datahämtning för att ge klienten befogenhet att specificera exakt de data som behövs från API:et. Det gör det lättare att utveckla API: er över tid.
Nu när vi vet vad GraphQL är vill jag klargöra vad det inte är, eftersom jag känner att det fortfarande finns viss förvirring om det.
För det första Det har inget med databaser att göra. Det är inte ett alternativ till SQL eller en helt ny ORM.
För det andra Det är inte en REST-ersättning, men ett alternativ. Du behöver inte välja mellan det ena och det andra, de kan gärna samexistera i samma projekt.
Sist men inte minst är GraphQL inte komplicerat eller skrämmande. Det är ganska lätt att förstå dess deklarativa natur och exakt hur det är möjligt att ta det bästa av det.
GraphQL utvecklades internt av Facebook 2012 innan den var öppen källkod 2015, med sin stabila version som släpptes precis i juni 2018. Den 7 november 2018 flyttades GraphQL-projektet från Facebook till den nyetablerade GraphQL Foundation, värd av den ideella Linux Foundation.
Lee Byron, GraphQL: s skapare, syftar till att göra GraphQL allestädes närvarande över webbplattformar.
GraphQL används av lag av alla storlekar, i många olika miljöer och språk. De viktigaste företagen som använder GraphQL är Facebook, Github, Pinterest och Shopify.
Innan jag går vidare till jämförelsen med REST kommer jag att gå igenom en enkel GraphQL-fråga där vi kan hämta en användare såväl som hans eller hennes namn och ålder:
Och JSON-svaret vi kommer att få från det:
Som jag nämnde tidigare gör GraphQL: s deklarativa karaktär det otroligt enkelt att förstå vad som händer hela tiden, eftersom vi i princip skriver JSON objekt utan värden.
REST definierades av Roy Fielding, en datavetare som presenterade REST-principerna i hans Doktorsavhandling år 2000.
REST (Representational State Transfer) är en programvara arkitektonisk stil som definierar en uppsättning begränsningar som gör vilken webbtjänst som helst - ett verkligt RESTful API. REST-begränsningarna är:
Klient-serverarkitektur innebär att användargränssnittsproblemen bör separeras från datalagringsproblemen för att förbättra användargränssnittets portabilitet över flera plattformar.
En statslös server behåller ingen information om användaren som använder API:et. Detta innebär att servern inte kommer ihåg om användaren skickar den första förfrågan eller inte.
REST API-svar måste definiera sig själva som cachelagbara eller icke-cachelagbara för att förhindra att klienter tillhandahåller olämpliga data som kan användas vid framtida förfrågningar.
Ett skiktat system innebär att om en ombud eller lastbalanserare placeras mellan klient och server, anslutningarna mellan dem bör inte påverkas, och klienten visste inte om den är ansluten till slutservern eller inte.
Ett enhetligt gränssnitt föreslår att det ska vara ett enhetligt sätt att interagera med en viss server trots enhet eller applikationstyp (webbplats, mobilapp). Huvudriktlinjen är att varje resurs måste identifieras på förfrågningar.
Med tanke på alla REST-begränsningar visar följande bild REST arkitektonisk stil:
Det finns två huvudorsaker till att företag som Facebook, Netflix och Coursera började utveckla alternativ till REST:
1. I början av 2010-talet var det en boom i mobilanvändningen, vilket ledde till vissa problem med lågdrivna enheter och slarviga nätverk. REST är inte optimalt för att hantera dessa problem;
2. I takt med att mobilanvändningen ökade ökade antalet olika front-end-ramverk och plattformar som kör klientapplikationer. Med tanke på REST: s oflexibilitet var det svårare att utveckla ett enda API som kunde passa varje kunds krav.
Om vi går ännu längre inser vi att den främsta anledningen till att en alternativ lösning identifierades var att de flesta data som används i moderna webb- och mobilapplikationer har en grafform. Till exempel, nyheter har kommentarer, och dessa kommentarer kan ha funktioner som gillar eller skräppostflaggor, som skapas eller rapporteras av användare. Det här exemplet beskriver hur en graf ser ut.
Följaktligen Facebook började utveckla GraphQL. Samtidigt arbetade Netflix och Coursera också med alternativ själva. Efter Facebooks open-source GraphQL släppte Coursera sina ansträngningar och antog den nya tekniken. Netflix fortsatte dock att utveckla sitt eget REST-alternativ och senare open source Falcor.
I nästa avsnitt kommer jag att förklara varför GraphQL möjliggör mer flexibilitet än REST, men låt oss först titta på dess arkitektur.
Är GraphQL bättre än REST? GraphQL tillhandahåller ett frågespråk som tillåter klienter att begära endast de data de behöver och möjliggör uppdateringar i realtid. REST förlitar sig på styva slutpunkter och datastrukturer. Huruvida GraphQL är ”bättre” beror på de specifika krav och flexibilitet som behövs i ett API-drivet projekt.
I det här avsnittet kommer jag att gå punkt för punkt genom ett praktiskt exempel, jämföra REST med GraphQL för att visa flexibiliteten i Facebooks frågespråk.
Tänk dig att du har en blogg, och du vill att förstasidan ska visa alla de senaste inläggen. För att uppnå detta måste du hämta inläggen, så du kommer förmodligen att göra något liknande:
HÄMTA /api/inlägg
Men tänk om du vill träffa författaren också? Du har tre alternativ för att uppnå detta:
Var och en av dessa tillvägagångssätt kommer att skapa ett eget problem, så låt oss titta på dem en efter en för att se hur GraphQL kan lösa följande problem.
Med det första tillvägagångssättet - att hämta författarna från en annan resurs - kommer du att sluta med två serverförfrågningar istället för en, och när du fortsätter att skala kan du ha ännu fler förfrågningar till olika slutpunkter för att hämta all nödvändig data.
Med GraphQL skulle detta inte hända. Du skulle bara ha en förfrågan, och du skulle inte behöva göra flera rundresor till servern, som visas nedan:
Om du tittar på det andra tillvägagångssättet - ändra resursen för att också returnera författaren - kan du se att det löste problemet ganska snyggt. Att ändra en resurs kan dock ha en sekundär effekt någon annanstans i programmet. Mer exakt, överhämtning.
Låt oss gå tillbaka till din blogg, men den här gången har du också en sidofält som visar de bästa månatliga inläggen med deras titlar, undertexter och datum, som använder resursen /api/inlägg. Eftersom du ändrade resursen visar den nu också författaren med den. Vi behöver dock inte det för sidofältet.
Även om detta kanske inte ser ut som ett problem, är det inte idealiskt för användare med begränsade dataplaner att ha en webbplats som hämtar värdelös data. Sedan GraphQL tillåter klienten att bara hämta nödvändig data, detta problem skulle inte existera:
Slutligen, låt oss ta en titt på det sista tillvägagångssättet - skapa en resurs som returnerar inläggen med författaren - eftersom det är ett vanligt mönster att strukturera slutpunkterna enligt vyerna i ditt projekt.
Även om detta kan lösa problem som det som beskrivs ovan, saktar det också ner frontend-utveckling, eftersom varje specifik vy behöver sin specifika slutpunkt. Om en vy vid något tillfälle behöver nya data måste utvecklingen sakta ner tills slutpunkten uppdateras.
Återigen, eftersom GraphQL ger klienten makt till hämta endast nödvändiga data, inget saktar ner, eftersom det är väldigt enkelt att bara lägga till ett nytt fält.
Du skulle få från detta:
Till detta:
Låt oss bara göra en snabb sammanfattning om skillnaderna mellan REST och GraphQL:
Som tidigare nämnts, GraphQL ersätter inte REST. Trots deras skillnader har GraphQL och REST också likheter:
FÅbegära med en URL och returnera begäran i JSON-data.Mutationoch Fråga types) är identisk med listan över slutpunkter i en REST API.Numera syftar nästan alla företag till att bygga mobila plattformsapplikationer eftersom kundinteraktionen med produkten ökar avsevärt om de kan komma åt den via sina telefoner. När du använder en mobilapp förväntar du dig att de ska vara lyhörda och med låg latens.
Genom att använda GraphQL kommer du att kunna uppnå dessa mål på ett riktigt enkelt sätt. Det hjälper klienten att hämta mängden data som behövs för att återge en specifik vy.
Fram till nu föreställer jag mig att vi delar samma åsikt att GraphQL är fantastiskt, men det är inte helt sant. Det finns fortfarande några saknade element för att göra det perfekt. Om du strävar efter att ha en av nästa punkter i ditt projekt bör du överväga användningen av REST.
Numera tillhandahåller varje webbläsare en implementering av en HTTP-cache för att enkelt undvika ometsning av resurser och för att identifiera om två resurser är desamma.
När du använder GraphQL finns det inget sätt att få en globalt unik identifierare för ett givet objekt eftersom vi använder samma URL för alla förfrågningar. Att ha cache på GraphQL måste du ställa in din egen cache.
När du använder REST kan du bygga ett övervakningssystem baserat på API-svar. På GraphQL har du inte det, eftersom det alltid återvänder 200 OK statussvar. Ett typiskt GraphQL-fel ser ut så här:
Om du tittar på detta svar kan du se att det är mycket svårt att hantera och övervaka olika felscenarier.
Som du nu vet kan du med GraphQL fråga exakt vad du vill när du vill, men vi bör vara medvetna om att detta leder till komplexa säkerhetskonsekvenser. Om en skadlig aktör försöker skicka in en dyr kapslad fråga för att överbelasta din server eller databas och din server inte har rätt skydd, kommer du att vara sårbar för DDoS (Denial-of-Service-attack) attacker.
Nu när vi vet hur det står sig mot REST, låt oss prata om några av de funktioner som är unika för GraphQL.
GraphQL använder sitt eget typsystem för att definiera schemat för ett API, med dess syntax kallad Schemadefinitionsspråk (SDL). Schemat fungerar som ett kontrakt mellan servern och klienten för att definiera hur en klient kan komma åt data.
När schemat är definierat, frontend och backend team kan arbeta självständigt, eftersom frontenden enkelt kan testas med mockdata. Front-end kan också få användbar information från schemat, till exempel dess typer, frågor och mutationer med hjälp av GraphiQL eller introspektion. Den GraphQLs schema ger också typsäkerhet, vilket är ett plus för front-end- och back-end-utvecklingen, eftersom det fångar typfel tidigt.
Ett schemaexempel:
GraphQL IDE är en av de mest användbara funktionerna i GraphQL-utveckling. Det utnyttjar sin självdokumenterande natur för att göra utvecklingen till en lek.
Använda GraphiQL eller GraphQL-lekplats, du kan bara inspektera ditt schema och till och med köra frågor och mutationer för att testa ditt API.
GraphQL ger en smidig och snabb utvecklingsmiljö med sin deklarativa och flexibla karaktär, erbjuder många förbättringar jämfört med REST.
Det har redan ett stort samhälle och ett levande ekosystem, och implementerades redan i Flera populära språk, såsom JavaScript, Gå och java.
Medan det här inlägget bara doppade tårna i havet som är GraphQL, är det hemsida har en uppsjö av information och är en fantastisk plats att lära sig och börja använda GraphQL.
Om du siktar på utveckla ett API som ska användas i en mobilapplikation du borde ha GraphQL som första alternativ eftersom bandbreddsanvändning spelar roll. Om din applikationen kräver ett robust API, med cachning och ett övervakningssystem Du bör gå med REST.
Med allt detta sagt är det inte en perfekt teknik, och det har fortfarande ett par nackdelar jämfört med REST. Men med tanke på hur ung den är ser framtiden otroligt ljus ut för GraphQL.
Webbutvecklare, brukar skriva null istället för nil. Älskar att utforska den funktionella stilen i Javascript.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
