Druhým častým problémem je expirace tokenu. Mnoho aplikací nastavuje příliš dlouhou platnost, třeba den nebo týden, aby uživatel nemusel často přihlašovat. To je ale past: pokud token unikne, útočník má dlouhý časový okno. Ideální je krátká expirace v řádu minut a kombinace s refresh tokenem. Refresh token pak musí být dlouhodobý, ale musí být uložen bezpečně, nejlépe v HttpOnly cookie s atributy SameSite a Secure. Při každém obnovení přístupového tokenu ověřte, že refresh token nebyl odvolán, a to buď na straně serveru, nebo pomocí blacklistu v databázi.<br>
<br>
<br>
<br>
REST je vhodný, když máte jasně definované zdroje a operace nad nimi. Typicky jde o CRUD aplikace, kde každý endpoint odpovídá jedné entitě – uživatel, objednávka, produkt. Výhodou je jednoduchost a předvídatelnost. Klient ví, že GET na konkrétní adresu vrátí vždy stejnou strukturu. To usnadňuje cacheování, logování i testování. Pokud ale potřebujete data z více zdrojů najednou, REST vás nutí k několika requestům, což může zpomalit aplikaci a zkomplikovat práci klienta.<br>
<br>
<br>
<br>
Nesmíte zapomenout ani na ověření příjemce tokenu (audience) a vydavatele (issuer). Token, který vydal jiný server, nebo token určený pro jinou službu, je nutné odmítnout. Bez této kontroly se může stát, že token z jedné aplikace použijete v druhé, a pokud obě běží na stejné doméně, útočník to snadno zneužije. Všechny tyto hodnoty musí být v tokenu přítomny a musí být kontrolovány při každém požadavku.<br>
<br>
<br>
<br>
Další chybou bývá přenášení citlivých dat přímo v payloadu JWT. Token je podepsaný, ale ne šifrovaný, takže jeho obsah si může přečíst každý, kdo ho získá. Do tokenu proto patří pouze identifikátory uživatele, role a případně další neveřejné, ale ne citlivé údaje. Hesla, čísla karet nebo osobní údaje do tokenu nikdy nepatří. Pokud potřebujete tokenem přenášet citlivé informace, použijte JWE, ale v drtivé většině případů je lepší token jen podepsat a data uchovávat na serveru.<br>
<br>
<br>
<br>
Rychlost načítání webu ovlivňuje nejen pozici ve vyhledávání, ale především to, zda návštěvník vůbec stihne zaregistrovat obsah, který jste mu chtěli ukázat. Často se řeší velikost obrázků nebo kvalita hostingu, ale skutečnou změnu přinese až systematický přístup. Začněte měřením – ne odhadem. Otevřete si vývojářské nástroje prohlížeče a podívejte se na čas do prvního vykreslení a na velikost hlavního vlákna. Tato dvě čísla vám řeknou, jestli je problém v síti, nebo ve špatně napsaném kódu.<br>
<br>
<br>
<br>
Pro většinu projektů je Express rozumnou volbou. Jeho hlavní výhodou je bohatý ekosystém middleware a jednoduchá definice cest. Začněte s minimálním nastavením: vytvořte instanci aplikace a nadefinujte základní trasy. Kolem každé trasy byste měli mít jasnou strukturu – rozdělte kód na kontrolery, služby a modely. Častou chybou začátečníků je psát veškerou logiku přímo do obsluhy trasy, což vede k obřímu souboru, který se špatně testuje a udržuje.<br>
<br>
<br>
<br>
Nakonec se zaměřte na to, co se děje při samotném zobrazování stránky. Pokud používáte hodně externích skriptů, které blokují vykreslení, prohlížeč čeká, až se načtou, a teprve poté ukáže stránku. To je nejhorší scénář. Řešením je načítat tyto skripty asynchronně, aby vykreslení neblokovaly. Typickým příkladem jsou chaty, widgety nebo mapy. Zkuste si srovnat, co je pro vaše návštěvníky skutečně důležité, a co je jen nadbytečná dekorace. Po každém odstranění jednoho zbytečného prvku znovu změřte rychlost. Nárůst rychlosti v řádu desetin sekundy je vidět i v uživatelských statistikách – okamžitě se projeví na nižším počtu opuštěných stránek.<br>
<br>
<br>
<br>
GraphQL řeší právě problém „příliš mnoho requestů" tím, že umožňuje v jednom dotazu získat přesně ta data, která potřebujete, a nic navíc. To oceníte u mobilních aplikací s omezeným datovým tarifem nebo u komplexních dashboardů, kde se kombinují data z různých částí systému. Místo aby server diktoval, co klient dostane, klient si definuje tvar odpovědi. Typickým příkladem je eshop, kde chcete zobrazit produkt, jeho varianty a skladové zásoby najednou – s GraphQL to zvládnete jedním voláním, s REST byste museli tři.<br>
<br>
<br>
<br>
Další věc, na kterou se zaměřit, je verzování API. U REST běžně verzujete pomocí URL (např. /v1/), u GraphQL se verzování obvykle řeší postupnými změnami schématu bez ostrých řezů. To je výhoda, ale jen pokud vaše týmová komunikace funguje dobře. Pokud máte externí partnery, kteří na vašem API staví, GraphQL může být problematický – změny v schématu mohou nenápadně rozbít jejich aplikace. REST s číslovanými verzemi dává jasný signál, že se něco mění.
