Když stavíš klienta, REST nebo GraphQL rozhodne o údržbě

Pro automatizaci rozhraní se používají frameworky, které umí ovládat aplikaci přes přístupnostní vrstvu nebo přes nativní rozhraní. Výhodou přístupnostní vrstvy je, že funguje napříč platformami, nevýhodou pomalejší běh a citlivost na změny popisků. Nativní nástroje jsou rychlejší a stabilnější, ale vyžadují samostatné testy pro každou platformu. Pro testování API se osvědčují nástroje, které umí opakovat požadavky, ověřovat odpovědi a simulovat výpadky sítě. Výkonnostní testy se dělají na reálných zařízeních, protože emulátor nereprodukuje zahřívání, spotřebu baterie ani chování paměti.

Typické chyby se opakují. Testovací data se zapisují natvrdo do kódu, takže testy padají při změně prostředí. Testy závisí na sobě navzájem a jejich pořadí rozhoduje o výsledku. Čekání se řeší pevnými prodlevami místo čekání na konkrétní stav, což vede k náhodným selháním. Automatizované testy se spouštějí jen na emulátoru a nikdy na skutečném zařízení. A často chybí testy pro obnovení stavu po přerušení – třeba když uživatel přijme hovor uprostřed nahrávání.

Nakonec se nebojte kombinace. REST pro veřejné a souborové endpointy, GraphQL pro složité čtecí scénáře uvnitř produktu. Rozhodujte podle konkrétních dotazů, které klienti posílají, ne podle toho, co zní moderněji. Změřte počet požadavků na obrazovku, velikost odpovědí a dobu odezvy. Teprve čísla ukážou, zda se vyplatí měnit architekturu.

Volba mezi REST a GraphQL se nepozná podle toho, co je modernější, ale podle tvaru dat a počtu klientů. REST je sada samostatných endpointů, každý vrací pevnou strukturu. GraphQL je jeden endpoint s dotazovacím jazykem, kde si klient určí, která pole chce. První otázka tedy zní: mají klienti podobné potřeby, nebo se výrazně liší? Pokud ano, GraphQL šetří přenos dat i počet verzí. Pokud ne, REST je jednodušší na pochopení i provoz.

Většina týmů dělá retrospektivu pravidelně, ale málokdy z ní něco vznikne. Schůzka se zvrhne v obecné stesky, několik lidí mlčí a za dvě hodiny se rozejdete s pocitem, že se nic nezměnilo. Příčina nebývá v lidech, ale ve formátu. Strukturovaná zpětná vazba je způsob, jak z rozhovoru vytáhnout konkrétní informace, které se dají řešit. Nejde o žádnou metodu z konference, ale o obyčejnou disciplínu v tom, jak lidé mluví.

Proč nestačí psát jen text bez struktu

Kde se rozhoduje v praxi GraphQL se vyplatí, když frontend skládá obrazovku z mnoha entit a nechce posílat pět požadavků. Jeden dotaz vrátí přesně to, co komponenta potřebuje. Naopak pro veřejné API, webhooky, nahrávání souborů nebo jednoduché CRUD operace je REST přirozenější. GraphQL nad soubory neumí dobře pracovat, stejně tak u dlouhých operací narazíte na to, že dotazovací jazyk není stavový. Pro běžné čtení a zápis jednoho záznamu je REST kratší cesta k hotové funkci.

Zvažte i tým a nástroje. GraphQL vyžaduje schéma, které se musí udržovat, a klienti často generují typy. To je výhoda v typovaných jazycích, ale znamená to další krok v CI. REST zvládne i malý tým bez speciálních znalostí. Pokud potřebujete rychle dodat první verzi a rozsah dat je malý, začněte RESTem. GraphQL přidejte ve chvíli, kdy vás opakované požadavky na složení dat skutečně brzdí, ne dřív.

Ještě než začneš psát kód, udělej dvě věci. Aktualizuj si main a novou větev vytvoř z něj, ne z větve, kterou máš otevřenou. Pojmenuj ji tak, aby z názvu bylo poznat, co řeší — třeba oprava-prihlaseni nebo filtr-faktur. Vyhni se názvům typu test, oprava nebo muj-ukol: za týden nikdo netuší, co v nich je. Větev drž krátce, ideálně na jeden problém. Dlouhá větev znamená mnoho konfliktů a hlavně nejistotu, jestli se ještě vůbec dá sloučit.

U RESTu platí, že čím víc klientů s odlišnými obrazovkami, tím víc endpointů nebo parametrů vzniká. Typická chyba je přidávat parametry jako include=author,comments,tags a postupně z toho udělat druhý, nezdokumentovaný jazyk. Řešení je verzovat API a držet každý endpoint odpovědný za jednu jasnou reprezentaci zdroje. U GraphQL je zrcadlově častou chybou nechat klienta dotazovat se do hloubky bez omezení. Nekonečné vnořování vztahů přetíží databázi. Nastavte limit hloubky dotazu a maximální počet objektů v jedné odpovědi.

U GraphQL počítejte s tím, že cache je složitější. HTTP cache podle URL nefunguje, protože vše jde na jeden endpoint přes POST. Musíte zavést vlastní cache na straně klienta nebo persistované dotazy. U RESTu stačí správně nastavit Cache-Control a ETag. Další častá chyba je u GraphQL bezmyšlenkovitě mapovat resolver na databázový dotaz. Vzniká N+1 problém. Řešením je dávkování požadavků v rámci jednoho resolveru, tedy načtení více záznamů jedním dotazem místo smyčky.