GraphQL vs. REST API, kterou architekturu zvolit?

API (application programming interface) patří mezi nejzákladnější prostředky využívané během programování webových i mobilních aplikací. S využitím HTTP zajišťují komunikaci mezi klientem a serverem, a současně umožňují rozšíření funkcionality daného nástroje i automatizaci specifických procedur. K tomuto účelu je dnes již standardně využívána architektura REST, které ovšem už nějakou dobu šlape na paty takzvané GraphQL.

Co je GraphQL

GraphQL je dotazovací jazyk (nikoli programovací), který je přímým konkurentem a současně nástupcem řešení REST API. Nabízí efektivnější přístup k tvorbě aplikačního rozhraní (API) a do značné míry ovlivnil styl, jakým jsou psané například React aplikace.

Technologie GraphQL se na trhu poprvé objevila v roce 2012 v souvislosti s vývojem nativní aplikace Facebook a je tedy původním výtvorem vývojářského týmu této, v současnosti, nejrozšířenější sociální sítě. V roce 2015 ji pak Facebook uvolnil jako open-source řešení a způsobil tak její masivní rozšíření napříč celým trhem.

Postupně se pro tento přístup tvorby moderních API rozhodovalo stále více organizací, mezi které dnes patří například GitHub, Shopify nebo sociální síť Pinterest. GraphQL funguje na úrovni aplikační vrstvy a mezi její největší přednosti oproti REST API patří snížení počtu dotazů na rozhraní.

Ve své podstatě se tak jedná o zjednodušení API, které usnadňuje práci zejména frontend vývojářů, jež se již nemusejí tolik zabývat stavem a změnami backendu.

GraphQL není závislý na žádné konkrétní implementaci, technologii ani produktu. Lze jej využívat se širokou škálou programovacích jazyků, JS frameworků (například již zmíněný React) nebo databází. Je to tedy obecný předpis toho, jak by spolu služby měly komunikovat a vzájemně si předávat data.

Využívá pouze jeden „endpoint“ a dynamicky se měnící data. Což znamená že pro požadovaný výsledek stačí poslat jen jeden dotaz (stejně jako se vypíše pouze jeden výsledek). Odpověď se pak navíc přizpůsobuje struktuře tohoto dotazu. Formát dotazu definuje formát odpovědi. Klient proto vždy dostane očekávaný výstup a pouze data o která požádal.

Vždy se tak pracuje pouze s daty, které jsou nezbytně nutné pro vykonání příslušného požadavku. To zajišťuje svižnější a spolehlivější reakce. Hlavním smyslem využívání GraphQL je tedy lepší strukturizace API pro mobilní i další aplikace.

Architektura GraphQL

Architektura GraphQL je postavena na několika základních vlastnostech, které definují její použití. Patří mezi ně:

• hierarchie – pole jsou uzpůsobena do hierarchické množiny, která umožňuje vždy pracovat pouze s konkrétní podmnožinou, to znamená, že server vždy pracuje se všemi daty, ale nazpět posílá pouze ta, o která požádal klient, lze tedy přímo specifikovat výstup, aniž by bylo zapotřebí pro každou informaci tvořit zvláštní příkaz,
• produktová orientace – z výše uvedeného již vyplývá, že podoba dotazu ani odpovědi není specifikována serverem, ale klientem (například webový prohlížeč), ten tedy určuje množství i formát přenášených dat,
• silná typovost – GraphQL má specifický typový systém pro danou aplikaci, dotazy jsou tak validovány ještě před jejich odesláním na server, což znamená, že jsou eliminovány případné chyby v podobě špatné syntaxe, nebo neplatného dotazu, současně se tímto způsobem šetří výpočetní výkon,
• introspektivnost – vývojáři mohou klást dotazy na typy, které server podporuje, tímto způsobem je usnadněno prozkoumávání konkrétní GraphQL API a předchází se tak zdlouhavému studiu implementačních kódů.

Technologie GraphQL navíc zjednodušuje verzování. Respektive se jedná o neverzovaný dotazovací jazyk. Nově přidané vlastnosti tak rozšiřují funkcionalitu, aniž by ovlivnily tu původní. Díky tomu je možné provádět rychlé a efektivní úpravy na frontendu aplikace.

Základní pojmy GraphQL

Mezi základní pojmy související s využíváním GraphQL bezpochyby patří schéma. Schéma funguje na pozici prostředníka mezi frontendem a backendem, přičemž jsou na jeho základě ověřovány všechny procházející dotazy. V první řadě je tedy nutné vytvořit a následně udržovat přehledné GraphQL schéma, které definuje všechny související položky, například typy obsažených objektů. K sestavení schématu je využíváno jazyka SDL.

Další pojem, se kterým se je možné během práce s GraphQL setkat jsou samotné dotazy, nazývané queries, ty vždy specifikují data, se kterými je třeba v rámci procesu pracovat, a současně stanovují podobu vrácené odpovědi. Užitečnou vlastností jsou pak takzvané fragmenty využívané pro deklaraci a následné volání opakujících se částí kódu.

Zmíněné části jazyka GraphQL tedy souvisejí se čtením dat. Pro zápis a modifikaci se využívají takzvané mutace (mutation).

Mohou se vyskytnout ve třech podobách – create, update a delete v závislosti na požadované modifikaci, přičemž současně mohou vrátit také hodnoty vytvořené na serveru, například přidělené ID. Pro vývoj real-time aplikací jsou pak velice užitečné subscriptions, které se mohou navázat na některou z událostí prováděnou na backendu a v souvislosti s ní provést předem určenou akci. Například zobrazit určitý výpis komentářů.

Výhody a nevýhody GraphQL

Dokumentace k technologii GraphQL specifikuje využití na třech úrovních. První z nich je práce s libovolnou databází, druhou variantou je působení GraphQL jako mezivrstvy mezi existujícími systémy. Lze ji tedy nasadit nad aktuální REST API a použít jako nástroj pro jednoduchou adresaci. V případě již existujícího řešení proto není nezbytně nutné předělávat celou implementaci. Poslední variantou je pak kombinace obou těchto řešení.

Výhody GraphQL již do jisté míry vyplynuly z původní specifikace architektury v předchozích odstavcích. Hlavní předností je tedy rychlost a stabilita aplikace, zapříčiněná klientskou specifikací dotazu – vždy dostane pouze, a právě ta data, která požaduje, nepřenáší se nic navíc. Data pocházející z několika zdrojů se, díky hierarchickému uspořádání, zobrazují na jednom místě. Aplikace tak zůstává svižná i na slabším mobilním připojení (EDGE).

Typový systém pak zajišťuje, že budou data validována ještě před vykonáním dotazu. Šetří se tak výpočetní výkon, který by byl v jiném případě vydán na neexistující žádost, nebo chybovou hlášku v souvislosti s chybou v syntaxi. Stručně řečeno se tak s přechodem na GraphQL snižuje provoz mezi frontendem a API.

Mezi nevýhody GraphQL pak patří zejména problémy s cachováním, kdy aktuálně neexistuje konkrétní specifikace pro jeho řešení. Stejně tak může nastat problém u zadávání dlouhých a komplexních dotazů. Většina režie pak zůstává na straně serveru, což navyšuje požadavky na jeho správu.

Příklad využití a syntaxe GraphQL

Obecný princip fungování API je postaven na interakci klienta se serverem. Uživatel tak například přes webový prohlížeč (klient) navštíví nějakou stránku, ku příkladu blog, a chce jej sdílet na svůj Twitter. Klikne tedy na tlačítko, které zavolá Twitter API, a to mu následně umožní tento příspěvek sdílet. Podobná situace může nastat, když provozovatel webu zadá programátorovi, aby vytvořil stránku s výpisem příspěvků publikovaných na blogu.

Ke každému z nich chce přidat informace o autorovi, datu publikace a tři poslední komentáře. V případě, kdy by k řešení vývojář přistupoval prostřednictvím REST API, by musel pro každý tento krok využít tři příkazy, zvlášť pro každý endpoint. Odpověď by pak obsahovala všechny informace o autorovi, o článcích a všechny komentáře (množství lze ovšem i zde specifikovat).  Došlo by tedy i ke stažení těch dat, která nejsou k tomuto úkolu nezbytně nutná.

Zde přichází na scénu GraphQL, které může nejen redukovat množství zpracovávaných dat, ale i snížit počet příkazů ze tří na jeden. Dojde tedy k odeslání jednoho požadavku a k jedné odpovědi obsahující všechna potřebná data, nic navíc.

GraphQL online

Pro názornost a lepší pochopení si pak můžete princip fungování GraphQL vyzkoušet pomocí nástroje GraphiQL bezplatně online. Níže uvedený screenshot znázorňuje příklad uživatelského dotazu, který požaduje výpis znění tří posledních komentářů spolu s údaji o uživateli a názvem příspěvku, ke kterému se vztahují.

K dispozici je zde příkladová API (endpoint), která lze ovšem změnit zadáním libovolné cesty. GraphiQL lze tedy využít také pro online testování a validaci vlastních GraphQL API.

Architektura REST

REST je architektura rozhraní pro distribuované systémy. Úzce souvisí s HTTP a je datově orientován. To znamená, že určuje způsoby, jakými lze přistupovat k datům. REST od sebe odděluje klientskou a serverovou část, díky čemuž je stejně jako GraphQL nezávislý na platformě a umožňuje nezávislý vývoj serveru a klienta. Klient pak při dotazech potřebuje znát URI čili endpointy (koncové body) na které se dotazuje.

Komunikace mezi klientem a serverem je bezestavová, server neukládá žádné informace a veškerou odpovědnost přenáší na klienta. Klient tedy musí dotaz uspořádat tak, aby byly využity všechny související koncové body, přičemž má každý zdroj svůj vlastní identifikátor, který musí být v případě nutnosti zavolán.

Za účelem snížení latence REST využívá cache, mezipaměť, do které ukládá dotazy při větším objemu dat, nebo před dalším použitím. Data tedy musejí být označena buď jako kešovatelná, nebo nekešovatelná. Pokud jsou kešovatelná, systém předpokládá, že se s nimi bude v budoucnu ještě pracovat a ponechá je ve zmíněné mezipaměti.

Touto cestou se zlepšuje výkon na straně klienta. Na druhou stranu ovšem narůstá šance na ztrátu aktuálnosti informací.

GraphQL API vs. REST API

Zásadní rozdíl mezi GraphQL API a REST API tedy spočívá ve způsobech pokládání dotazů a v jejich počtu. Zatímco REST funguje na principu koncových bodů, které se vztahují ke každému zdroji, si lze GraphQL představit spíše jako grafovou strukturu, případně množinu bodů s pouze jedním endpointem.

Rozdíl lze spatřovat také v definování zdrojů a jejich struktury pro klienty. U REST API tato úloha spočívá na serveru. Klient tak dostává všechna data a při jejich změně se musí přizpůsobit.

U GraphQL tato úloha spočívá na klientovi. Klient tedy sám určuje formát přijímaných i odesílaných dat a získává je z jedné zanořené struktury. Tím, že nepracuje s daty, které přímo nepotřebuje se tak může vyhnout například složitějším operacím a snížit nároky na výpočetní výkon.

Nedochází k takzvanému overfetchingu čili stahování nadbytečných dat a přetěžování systému. REST API také hůře reaguje na změny ve frontendu, přičemž vždy hrozí riziko, že dojde ke zpomalení souvisejících operací. Na druhou stranu je však toto řešení obecně považováno za bezpečnější a díky delší době na trhu také propracovanější, zároveň však složitější na osvojení. 

Lze tedy jen obtížně zvolit jednoznačného vítěze souboje GraphQL vs. REST API. Obě řešení mají svá pro a proti a je proto vždy vhodné jejich využití zvážit v souvislosti s konkrétními požadavky na funkcionalitu aplikace. Obecně se dá ovšem říci, že má technologie GraphQL potenciál pro to, aby v budoucnu REST API zcela nahradila.

Pokud potřebujete poradit s konkrétním problémem, neváhejte využít naší bezplatné konzultace, kde můžeme společně probrat to nejlepší možné řešení pro vás.