Lekce 1 - GraphQL - GraphQL vs. REST

Vítejte v kurzu GraphQL. V následujících tutoriálech se seznámíme s tím, jak efektivně vytvářet a používat dotazy na data pomocí GraphQL. Prozkoumáme základní koncepty, jak definovat a manipulovat datové schéma, jak integrovat GraphQL do JavaScriptových aplikací a další. Během kurzu získáme praktické dovednosti a porozumění k tomu, jak využít plný potenciál GraphQL ve vývojovém procesu.

Předpoklady pro úspěšné zvládnutí kurzu

Pro absolvování kurzu je nutná orientace v JavaScriptu alespoň na úrovni našich kurzů Základní konstrukce jazyka JavaScript a Objektově orientované programování v JavaScriptu. Důležité je také porozumění tomu, co je API, jak fungují HTTP požadavky a odpovědi a jak se používají pro komunikaci mezi klientem a serverem. Užitečné budou také znalosti alespoň některého z frameworků Angular, Vue či React.

GraphQL

Světlo světa GraphQL spatřilo roku 2012. Autorem je firma Meta Platforms (dříve Facebook), která jej vyvinula pro potřebu efektivní a rychlé komunikace mezi mobilními zařízeními. V roce 2015 byl kód uvedený jako open source (otevřený zdrojový kód) a nyní je ve vlastnictví GraphQL Foundation. GraphQL najdeme u mnoha velkých firem jako jsou Meta Platforms, GitHub, Pinterest, Twitter, Atlassian (BitBucket), Shopify, Paypal a další.

K čemu je GraphQL dobré

Většina aplikací dnes potřebuje získávat data ze serveru, kde jsou tato data uložena v databázi. Odpovědností API je poskytnout rozhraní pro uložená data, které odpovídá potřebám aplikace. GraphQL je často zaměňované za databázovou technologii, což je mylná představa. GraphQL je multiplatformní dotazovací jazyk pro naše API a běhové prostředí na straně serveru pro provádění dotazů podle jasně definovaného typového schématu.

Typové schéma přesně definuje formát dat, které si budou klient a server mezi sebou vyměňovat. Lze jej použít v čistém Javascriptu i nasadit do našeho oblíbeného frameworku. Lze jej používat se širokou škálou programovacích jazyků jako jsou PHP, Java, Kotlin, Python, Perl, C# .NET, C, C++ a mnoho dalších.

Proč GraphQL, když máme REST?

Hlavní výhoda GraphQL spočívá v jediném přístupovém bodu. V konkurenčním REST máme pro každý zdroj dat zvláštní přístupový bod. Jako příklad si ukážeme API pro aplikaci na blogování. Představme si situaci, kdy na straně klienta budeme chtít zobrazit najednou uživatele, jeho jméno a poslední tři sledující daného uživatele. Přístupové body pak vypadají např. takto:

Při použití REST potřebujeme tři kroky pro načtení potřebných dat:

Pro získání potřebných dat je zapotřebí se připojit ke všem třem přístupovým bodům a stáhnout všechna data. Včetně těch, která nepotřebujeme.

V GraphQL nám stačí jeden přesně formulovaný dotaz:

Zásadní rozdíl v přístupu REST a GrapQL je tedy v následujícím:

1. REST pro komunikaci s databází používá různé metody (součásti protokolu HTTP). Nejčastěji používané metody jsou GET pro čtení dat, POST pro přidání nových dat, PUT pro změnu existujících dat a DELETE pro smazání dat.
2. Naproti tomu GraphQL používá základní dotaz (Query), který zastává funkci načítání dat. Pro vše ostatní, jako je úprava, vkládání a mazání dat se používá mutace (Mutation).

Podívejme se na srovnání v tabulce:

Výhody systému schémat a typů

GraphQL využívá silný typový systém k definování schopností API. Všechny typy, které jsou vystaveny v rozhraní API, jsou zapsány do schématu pomocí GraphQL jazyka SDL (Schema Definition Language). Toto schéma je jako smlouva mezi klientem a serverem, která definuje, jak může klient přistupovat k datům. Jakmile je schéma definováno, týmy pracující na frontendu a backendu mohou dělat svoji práci bez další komunikace, protože oba znají přesnou strukturu dat odesílaných přes síť, čímž se vyvarují přehnanému nebo nedostatečnému načítání dat.

Overfetching a underfetching

A právě přetížení a nedostatečné načítání dat je jedním z nejčastějších problémů REST. Dochází k němu, protože jediný způsob, jak může klient stáhnout data, je připojit se k určitým koncovým bodům (URL adresám), které vrací pevně dané struktury dat. Je velmi obtížné navrhnout takové API, které by klientům poskytovalo přesné datové potřeby.

Overfetching tedy znamená, že klient stáhne více dat než je skutečně potřeba. Pokud například chceme zobrazit pouze seznam jmen uživatelů, koncový bod nám vrátí pole JSON, které často obsahuje více informací než potřebujeme.

Opačným problémem je underfetching. Underfetching obecně znamená, že konkrétní koncový bod neposkytl dostatek požadovaných informací. Klient pak musí provést další požadavky, aby získal vše, co potřebuje.

GraphQL je v těchto aspektech lepší, protože umožňuje klientům specifikovat přesně, jaká data potřebují. Tento přístup eliminuje jak overfetching, tak i underfetching. Toto je zvláště užitečné v mobilních aplikacích, kde jsou šířka pásma a výkon klíčovými faktory.

Rychlá změna na frontendu

Běžným vzorem s rozhraním REST je strukturování koncových bodů podle zobrazení, která máme ve své aplikaci. To je užitečné, protože umožňuje klientovi získat všechny požadované informace pro konkrétní pohled pouhým přístupem k odpovídajícímu koncovému bodu. Hlavní nevýhodou tohoto přístupu pak je, že neumožňuje rychlou změnu na frontendu. S každou změnou, která je provedena v uživatelském rozhraní, existuje vysoké riziko, že je nyní potřeba více (nebo méně) dat než dříve. V důsledku toho je potřeba upravit i backend, aby zohlednil nové potřeby dat. S GraphQL je tento problém vyřešen. Díky jeho flexibilitě lze změny provádět bez jakékoliv změny na serveru.

Nevýhody GraphQL

Stejně jako i v jiných oblastech je každá kladná vlastnost vyvážena jinou negativní. Nevýhodou jediného přístupného bodu je to, že není možné se jednoduchým dotazem doptat na všechna data, například jako u jazyka SQL (dotazem SELECT * FROM table;). Pokud chceme získat všechna dostupná data, musíme vyjmenovat všechny atributy.

Při používání REST jsme si také navykli používat HTTP statusy v odpovědích a případně na ně reagovat na frontendu. U GraphQL můžeme pouze počítat s HTTP statusem 400 při chybném požadavku a pro vše ostatní je HTTP status 200. Ostatní chyby, které mohou nastat, budou zapsány v JSON odpovědi.

Příklad chyby na neexistující dotaz:

{
    "data": null,
    "errors": [
        {
            "message": "Validation error of type FieldUndefined: Field 'ahoj' in type 'Query' is undefined @ 'ahoj'",
            "locations": [
                {
                    "line": 2,
                    "column": 5,
                    "sourceName": null
                }
            ],
            "description": "Field 'ahoj' in type 'Query' is undefined",
            "validationErrorType": "FieldUndefined",
            "queryPath": [
                "ahoj"
            ],
            "errorType": "ValidationError",
            "path": null,
            "extensions": null
        }
    ]
}

Pro úvodní seznámení s GraphQL a základní srovnání s REST jsme si toho již řekli dost. Pro tuto lekci je to tedy vše.

V příští lekci, Datové typy, schéma a dotazy v GraphQL, se podíváme na primitivní datové typy, základní konstrukci schématu a ukážeme a vyzkoušíme si první dotazy.