Statické typy versus dynamika: proč se vyplatí TypeScript
Jak vypadá zdravá hierarchie a kde ji nejčastěji rozbijete Funkční základ pyramidy tvoří jednotkové testy. Měly by pokrývat izolovanou logiku bez závislostí na databázi, síti nebo časovačích. Pokud test potřebuje připojení k databázi nebo mockování pěti vrstev, není to jednotkový test, ale integrační test v převleku. Integrační testy patří do prostřední vrstvy – ověřují spolupráci modulů, ale stále by měly být rychlé a stabilní. Na vrcholu stojí malý počet E2E testů, které kontrolují kritické uživatelské cesty. Častá chyba? Píšete E2E testy pro každou maličkost, protože „to je přece nejvěrnější simulace". To je cesta do pekla.<br>
<br>
<br>
<br>
Asynchronní chyby a handling rout Jakmile začnete používat async funkce v routách, narazíte na to, že Express 4 nezachytává výjimky z promise řetězců automaticky. Pokud v async handleru dojde k chybě, Express ji nezpracuje a server může spadnout. Řešením je buď obalit každou trasu pomocnou funkcí, která chybu předá do next(), nebo přejít na Express 5, který async chyby zvládá nativně. Nezapomeňte také na centrální error middleware, který zachytí chyby z celé aplikace a vrátí uživateli smysluplnou odpověď.<br>
<br>
<br>
<br>
Když se řekne databáze, většině vývojářů se vybaví tabulky s řádky a sloupci, tedy klasický SQL. Jenže moderní aplikace často pracují s daty, která se do pevné struktury nevejdou – třeba s dokumenty, grafy nebo časovými řadami. Právě pro tyto případy existuje NoSQL. Nejedná se o jednu technologii, ale o rodinu databází, které se liší způsobem ukládání i dotazování. Než se do NoSQL pustíte, je důležité pochopit, kdy dává smysl a kdy naopak zvolit osvědčený SQL.<br>
<br>
<br>
<br>
Když stavíte REST API v Node.js s frameworkem Express, rychle narazíte na to, že samotné definování tras nestačí. Klíčové je nastavit si strukturu projektu tak, aby se v něm dalo dlouhodobě pracovat. Místo psaní veškeré logiky do jednoho souboru oddělte routery od kontrolerů a služeb. Každá vrstva pak má jasnou odpovědnost: router mapuje URL, kontroler ověřuje vstupy a služba komunikuje s databází. Tím se vyhnete situaci, kdy po třech měsících vývoje přestanete rozumět vlastnímu kódu.<br>
<br>
<br>
<br>
Druhý krok: zaměřte se na mockování API volání. Async akce většinou volají nějakou službu, kterou je nutné nahradit. Pomocí vi.fn() nebo jest.fn() vytvoříte mock, který vrací předem připravená data. Důležité je ověřit, že akce správně zpracuje úspěch i chybu. Například test, že při chybě dispatchne akci s typem ERROR a nepokračuje dál. Vyhnete se tak tomu, že se v reálném prostředí objeví neošetřená výjimka.<br>
<br>
<br>
<br>
Typickou chybou je také nesprávné používání HTTP metod. Často vidím, že se pro mazání zdroje používá POST nebo že se stav mění přes GET. Držte se konvencí: GET na čtení, POST na vytváření, PUT nebo PATCH na úpravu a DELETE na smazání. To není jen formalita – správné metody usnadňují práci klientům i nástrojům pro testování. Navíc si usnadníte implementaci cache a automatické dokumentace.<br>
<br>
<br>
<br>
Poslední rada: pyramidu neberte jako dogma, ale jako výchozí bod. U projektu s bohatým uživatelským rozhraním a složitou logikou na klientovi bude poměr jiný než u REST API bez frontendu. Důležité je, abyste se rozhodovali vědomě a ne náhodně. Měřte si dobu běhu, počet selhání a čas strávený údržbou. Jakmile uvidíte, že opravy testů žerou víc času než psaní nových funkcí, je čas pyramidu přebudovat. A to je přesně ten moment, kdy se vyplatí mít na paměti, proč pyramida existuje – ne pro krásu, ale pro efektivitu.<br>
<br>
<br>
<br>
Při návrhu API se vyplatí myslet na verzování. I když to na začátku vypadá jako zbytečná práce, později vám to ušetří spoustu bolesti. Nastavte verzi v URL, například /api/v1/uzivatele, nebo použijte hlavičky. Změny v API pak můžete zavádět postupně, aniž byste rozbili aplikace, které na vašem API běží. Starší verze můžete po čase odstranit, ale mějte vždy dostatečně dlouhou dobu na migraci.<br>
<br>
<br>
<br>
Zkuste si osvojit jeden zvyk — při každé úpravě souboru se podívejte, jestli můžete něco zjednodušit. Nemusíte předělávat vše najednou, stačí jedna malá změna denně. Postupně se vám kód stane přirozeně čistším a ušetříte hodiny při ladění. Až příště narazíte na funkci, které nerozumíte po pěti sekundách čtení, víte, co dělat — přejmenujte ji, rozdělte ji nebo ji úplně smažte.<br>
<br>
<br>
<br>
Druhým častým problémem je chybějící validace dat. Express sám o sobě žádnou validaci nenabízí, takže pokud nepoužijete nástroj jako Joi nebo zod, musíte kontrolovat každý vstup ručně. Ověřte, že povinná pole existují, mají správný typ a délku. Vracejte chybové odpovědi s odpovídajícím HTTP statusem – pro neplatná data použijte 400, pro neoprávněný přístup 401. Vyhnete se tím situacím, kdy klient dostane status 500 kvůli špatně zadanému e-mailu.