Kdy REST ničí výkon a GraphQL zbytečně komplikuje

Simulace dat a vazeb v pra

Pozor na časové limity uvnitř samotné úlohy. Pokud úloha po dvou sekundách vzdá práci, test s delším čekáním ji nezachrání. Nastavte limity konfigurovatelně a v testech je zkraťte nebo naopak prodlužte podle potřeby. Zároveň logujte každý přechod stavu, protože při pádu testu je z logu hned vidět, ve které fázi se úloha zasekla.

REST se vyplatí tam, kde jsou zdroje jasně oddělené a odpovědi se moc nemění. Typicky jde o veřejné rozhraní, jednoduché integrace mezi službami nebo situace, kdy je potřeba využít HTTP cache. Praktický postup: navrhněte zdroje jako podstatná jména, použijte správné metody a stavové kódy, nastavte cacheovací hlavičky. Pokud ale klient volá pět endpointů, aby složil jednu obrazovku, narazíte na zbytečné dotazy navíc a REST začne být pomalý.

Moduly přinášejí čistší strukturu, ale mají vlastní pravidla. Importy se vyhodnocují jednou a platí pro celý běh aplikace, takže vedlejší efekty v modulu se spustí i tam, kde je nečekáš. Pojmenované importy musí přesně odpovídat exportům, jinak dostaneš chybu při načtení, ne za běhu. Výchozí export se importuje pod libovolným názvem, což svádí k nekonzistenci v projektu. Drž se jednoho stylu a názvy souborů i exportů udržuj shodné.

Funkce, která načte data, přepočítá je, vykreslí do tabulky a ještě odešle událost, dělá příliš mnoho věcí. Rozdělte ji. Každá funkce by měla dělat jednu věc a dělat ji celou. Prakticky to znamená, že byste měli být schopni funkci popsat jednou větou bez spojky „a". Když se do věty „a" vrací, je čas funkci rozříznout. Kratší funkce se snáze testují, snáze se v nich hledá chyba a méně často vedlejší efekty uniknou pozornosti.

Rozhodnutí zkuste ověřit na jednom reálném případu. Vezměte obrazovku, kterou klient skládá z dat, a spočítejte, kolik dotazů by vyžadoval REST a kolik resolverů GraphQL. Pokud REST vychází na jeden nebo dva požadavky, zůstaňte u něj. Pokud jich potřebujete víc a mění se podle kontextu, GraphQL vám ušetří práci. Ať zvolíte cokoli, nástroj sám nevyřeší špatný návrh dat. Ten je potřeba mít hotový dřív, než napíšete první řádek schématu nebo první endpoint.

U větších systémů se oba přístupy běžně kombinují. REST zůstává pro interní služby a veřejné rozhraní, GraphQL se nasadí jako vrstva pro klientské aplikace. Na co si dát pozor: autorizace musí být v GraphQL řešená na úrovni polí, ne jen na vstupním bodě. Chybí-li kontrola u konkrétních atributů, může klient získat data, která mu nepatří. Stejně tak u REST nepodceňujte verzování. Změna struktury odpovědi bez nové verze rozbije všechny stávající klienty.

Kde GraphQL řeší problém a kde ho sám vytváří GraphQL dává smysl, když čelní aplikace potřebuje různé kombinace dat a REST by znamenal desítky speciálních endpointů. Klient pošle dotaz, server vrátí přesně to, co je potřeba. Jenže tady vzniká nejčastější past: takzvané N+1 dotazy. Každé pole v odpovědi může spustit samostatný dotaz do databáze, a pokud se to nevyřeší dávkováním nebo dataloadery, výkon se zhroutí. Druhá past je neomezená hloubka dotazu. Bez limitu může klient poslat rekurzivní strukturu, která položí server.

Jakmile si na verzování zvykneš, zjistíš, že ti šetří nejen čas, ale i nervy. Můžeš bez obav zkoušet nové postupy, protože víš, že se vždy můžeš vrátit k předchozímu stavu. Až budeš pracovat v týmu, budeš potřebovat i vzdálený repozitář a pravidelný push, aby ostatní viděli tvoji práci. Začni dnes, klidně na malém projektu — čím dřív si návyk vytvoříš, tím přirozenější ti bude.

Praktické zásady pro GraphQL: nastavte maximální hloubku dotazu, zakažte příliš drahé operace, měřte dobu jednotlivých resolverů a logujte pomalé dotazy. U REST zase hlídejte, aby se endpointy nezačaly množit podle obrazovek. Jakmile najdete endpoint typu „vrat-vse-pro-hlavni-stranku", znamená to, že se REST snaží dělat práci GraphQL a dělá ji špatně.

Volba mezi REST API a GraphQL není otázka modernosti, ale konkrétního tvaru dat a způsobu, jakým je klient bude používat. REST staví na pevně daných endpointech, kde každá adresa vrací předem definovanou strukturu. GraphQL nabízí jeden vstupní bod a klient si sám určí, která pole potřebuje. První chyba, kterou lidé dělají, je rozhodování podle popularity nástroje místo podle toho, jestli data mají pevnou nebo proměnlivou podobu.

Mezi časté chyby patří ukládání příliš velkých souborů, jako jsou videa nebo obrázky ve vysokém rozlišení, přímo do repozitáře. Ten se tím nafoukne a práce s ním se zpomalí. Další častou chybou je práce pouze v jedné větvi a dlouhé období bez commitu. Když pak chceš vrátit změnu, musíš rozplétat desítky nesouvisejících úprav. Commitovat bys měl po menších logických celcích, ideálně několikrát denně. Také se vyhýbej nahrávání citlivých údajů, jako jsou přístupové klíče nebo konfigurace databáze. Ty patří do ignorovaných souborů nebo do proměnných prostředí.