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

Pro oddělení se vyplatí zavést šablony a generátory. Konfigurační soubory pište jako šablony s placeholdery a hodnoty doplňujte při nasazení z bezpečného úložiště. Tím se konfigurace stává reprodukovatelnou a verze kódu určuje, jaké klíče aplikace očekává. Když se změní název proměnné, změní se i šablona, ale hodnoty zůstávají mimo repozitář. Výsledkem je, že historie kódu je čistá a konfigurace se dá kdykoli vrátit zpět bez zásahu do zdrojáků.

Kde se čas ztrácí nejčastěji Největší skrytá položka bývá čekání a přepínání kontextu. Čekání na odpověď v diskusi, na schválení pull requestu, na dostupnost prostředí nebo na kolegu, který má jinou práci. Přepínání mezi úkoly pak snižuje efektivitu — návrat do rozpracovaného problému trvá déle než pár minut. Do odhadu patří i čas na zapracování po přerušení, ne jen čistý čas u klávesnice.

Propojení obou repozitářů řešte při nasazení, ne v kódu. Aplikace by měla konfiguraci načítat z předem dané cesty nebo z proměnných prostředí, nikoli odkazovat na konkrétní soubor v repozitáři s kódem. Názvy klíčů a strukturu formátu držte v obou repozitářích shodné, ideálně popsané jednou šablonou. Když se formát změní, upravte šablonu v repozitáři s kódem a hodnoty v repozitáři s konfigurací. Rozdíl odhalíte testem, který ověří, že všechny povinné klíče jsou přítomné.

Rozdělte repozitáře podle toho, kdo co vlastní Prvním krokem je rozhodnout, co je kód a co konfigurace. Kód patří vývojářům, prochází review a vydává se ve verzích. Konfigurace patří provozu nebo konkrétnímu prostředí a často ji spravuje jiný tým. Založte dva repozitáře: jeden pro aplikaci, druhý pro konfiguraci. Pokud to nejde kvůli nástrojům, použijte alespoň oddělené větve s ochranou a jasným vlastníkem. Do repozitáře s kódem nikdy necommitujte soubory s hesly, tokeny ani connection stringy. Místo toho používejte soubory, které se načítají z prostředí nebo z externího úložiště.

Na co si dát pozor: nepleť si skryté činnosti s neznámem. Neznámo se řeší prototypem nebo časově ohraničeným průzkumem, ne přidáním rezervy. Také si neber odhad jako závazek — je to predikce za určitých předpokladů. Když se předpoklady změní, změň i odhad a řekni to včas. Nejčastější chyba není špatné číslo, ale to, že se o změněných podmínkách mlčí až do konce.

Praktický postup je rozdělit odhad na dvě části. První je čistá práce, kterou umíte pojmenovat. Druhá je režie, kterou odhadnete z historie. Pokud z posledních pěti úkolů vychází, že režie tvořila zhruba třetinu času, použijte stejný podíl i nyní. Nejde o přesné číslo, ale o vědomé zahrnutí místo jeho ignorování. U delších úkolů režie neroste lineárně — čím více lidí a systémů je zapojeno, tím více času spotřebuje koordinace.

Začněte tam, kde to bolí nejvíc. Nemá smysl zavádět celou kulturu naráz. Vyberte jednu službu, která se nasazuje ručně, často padá nebo na její vydání čeká tým příliš dlouho. Sepište, co všechno se dnes musí udělat od commitu po běžící verzi. Zjistíte, že velká část kroků jsou ruční úkony bez zápisu, které závisí na jednom člověku. Právě ty jsou první cíl.

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.

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ě.

Když odhaduješ čas na vývojový úkol, pravděpodobně počítáš s psaním kódu, testováním a možná code review. Skryté činnosti ale tvoří často třetinu až polovinu skutečné práce. Nejde o práci navíc, kterou bys měl „přidat jako rezervu" — jde o činnosti, které reálně nastanou a které je možné pojmenovat a odhadnout zvlášť.

Začni tím, že si před odhadem sepíšeš, co všechno bude potřeba udělat před samotným kódem. Patří sem čtení existujícího kódu, dohledávání, proč je něco udělané určitým způsobem, konzultace s někým, kdo tomu rozumí, a příprava testovacích dat. Tyto činnosti se snadno schovají pod „implementaci", ale mají vlastní trvání. Když je vypíšeš jako samostatné položky, přestanou být neviditelné.