Měření pokrytí testy, které jen zdržuje vývoj

První krok je oddělit odhad od závazku. Když zákazník chce termín, řekněte nahlas, co ten termín znamená: „Tohle je můj odhad za předpokladu, že dostanu podklady do středy a nikdo nezmění zadání." Tím se z odhadu stává podmíněný výrok, ne příslib. Zákazník pak ví, co se musí stát, aby termín platil, a vy máte páku, když se podmínky změní. Bez této věty se každý posun termínu jeví jako vaše selhání.

TypeScript není nový jazyk, který bys musel učit od nuly. Je to JavaScript s typovou vrstvou, kterou projde kompilátor a teprve pak vznikne spustitelný kód. V praxi to znamená, že do stávajícího projektu přidáš soubor tsconfig.json, přejmenuješ část souborů z .js na .ts a postupně doplňuješ typy. Nemusíš přepisovat všechno najednou. Kompilátor umí být nastavený tak, že chybějící typy nehlásí jako chybu, takže migrace může být plynulá.

Implementace JWT není složitá, ale chyby v detailech mají vážné důsledky. Držte se zásady nejmenšího oprávnění, kontrolujte všechny relevantní claimy a nikdy nedůvěřujte tokenu bez ověření podpisu. Pravidelný audit a testování zranitelností by měly být samozřejmostí.

Při vytváření tokenu je klíčová volba algoritmu. HS256 (symetrický) používá stejný klíč pro podpis i ověření – je vhodný, když token vydává i ověřuje stejná služba. RS256 (asymetrický) odděluje soukromý klíč pro podpis a veřejný pro ověření, což je bezpečnější pro distribuované systémy. Nikdy nepoužívejte algoritmus „none" a vždy ověřujte, že token byl podepsán očekávaným algoritmem. Útočník by mohl podstrčit token s alg: none a získat neoprávněný přístup.

Na co si dát pozor v praxi Doba platnosti tokenu by měla být krátká – typicky 15 minut až hodina. Pro delší relace použijte refresh token, který má delší platnost a lze jej revokovat. Refresh token ukládejte bezpečně, ideálně v httpOnly cookie, nikdy v localStorage. Přístupový token naopak může být v paměti nebo v cookie s příznakem Secure a SameSite. Vyhněte se ukládání citlivých údajů do payloadu – token je pouze podepsaný, ne šifrovaný, takže si jej kdokoli může přečíst.

Kde GraphQL šetří síť a kde přidělává práci GraphQL přesouvá skládání dat na server. Klient pošle dotaz, dostane přesně ta pole, která potřebuje, a jedním requestem vyřeší i vnořené vztahy. To je výhoda na pomalých mobilních sítích a u obrazovek, které kombinují data z mnoha entit. Zároveň ale vzniká nová vrstva: resolver, schéma a ochrana proti příliš hlubokým dotazům. Bez omezení hloubky a počtu uzlů se z jednoho dotazu stane neplánovaný join přes celou databázi. Chyba, kterou dělá mnoho týmů, je pustit GraphQL do produkce bez limitu komplexity a bez sledování pomalých dotazů.

U GraphQL se také mění práce s cache. HTTP cache na úrovni URL zmizí, protože vše jde na jeden endpoint přes POST. Řešením je persistované dotazy, cache na úrovni resolverů nebo dedikovaná vrstva. Pokud tým nemá kapacitu na monitoring a optimalizaci dotazů, bývá REST levnější na provoz i na údržbu. Naopak pokud klienti neustále žádají nové kombinace polí, REST se zvrhne v desítky účelových endpointů a GraphQL je čistší.

Častou chybou je neošetřená expirace. Vždy kontrolujte claim „exp" a při vypršení tokenu vracejte 401 Unauthorized s jasnou zprávou. Pokud tokeny vydáváte více službám, nastavte správné „aud" (audience) a „iss" (issuer). Bez těchto kontrol může token vydaný pro jinou službu získat přístup tam, kam nepatří. Dále nikdy neposílejte token v URL – může se dostat do logů a historie prohlížeče.

Pro bezpečný přenos používejte výhradně HTTPS. Token v hlavičce Authorization je sice běžný, ale bez TLS jej může odposlechnout kdokoli na síti. Při nasazení za proxy nebo API bránou ověřte, že nedochází k přepisování hlaviček. Zvažte také rotaci podpisových klíčů – staré klíče nechte chvíli platné pro ověření, ale nové tokeny podepisujte klíčem novým. Tím předejdete výpadkům při kompromitaci klíče.

Začněte tím, že si prohlédnete, které části kódu jsou kritické. Platební logika, výpočty, zpracování vstupů od uživatele, přístupová práva. Tam má pokrytí smysl a tam se vyplatí investovat čas. Naopak gettery, settery, konfigurační soubory nebo jednoduché přepisy hodnot testovat nemusíte. Napsat pro ně test je snadné, ale hodnota je nulová a jen zvyšuje číslo.

JWT (JSON Web Token) je kompaktní, samostatný token, který nese informace o uživateli a jeho oprávněních. Skládá se ze tří částí: hlavičky, payloadu a podpisu. Hlavička určuje algoritmus podpisu, payload obsahuje tvrzení (claims) – např. identifikátor uživatele, roli, čas expirace. Podpis zaručuje, že token nebyl pozměněn. Token se obvykle předává v hlavičce Authorization: Bearer . Výhodou je bezstavovost – server nemusí ukládat relace, což usnadňuje škálování.