Co zrobić, aby stránky nabíhaly svižně i na pomalém připojení?
Délka funkce je dalším spolehlivým indikátorem. Funkce nad dvacet řádků obvykle dělá víc věcí najednou. Rozdělte ji podle odpovědnosti: jedna funkce má mít jeden důvod ke změně. Když se v těle objeví víceúrovňové vnořené podmínky, použijte takzvané guard clauses — na začátku odchytte neplatné vstupy a vraťte se brzy. Vyhnete se tak zanořování, které se po pár úpravách změní v nečitelný blok.
Nejužitečnější novinkou je async/await, ale i tady platí, že bez ošetření chyb vzniká tichý problém. await uvnitř cyklu znamená sekvenční čekání; pokud na sobě operace nezávisí, spusť je přes Promise.all a výsledky zpracuj najednou. Vždy obal volání do try/catch, protože odmítnutý promise bez zachycení shodí aplikaci. A nezapomeň, že funkce s await musí být sama async — jinak dostaneš syntaktickou chybu, kterou někteří editoři odhalí pozdě.
Typické chyby, na které narazíte: optimalizace naslepo bez měření, přehnané vkládání všeho do jednoho obřího souboru, který se stejně celý nevyužije, a testování jen na rychlé firemní síti. Vyzkoušejte stránku i na mobilních datech a se simulovaným zpomalením. Po každé změně měřte znovu a porovnávejte stejnou metriku. Zlepšení o desítky procent bývá reálné už po úpravě obrázků, komprese a cache, tedy bez zásahu do kódu aplikace.
Pro jednoduché případy postačí middleware, který si drží počítadlo požadavků v paměti. Funguje to tak, že si ke klíči (IP adresa, API klíč, uživatel) uložíte počet požadavků a časové razítko. Při každém požadavku zkontrolujete, zda nevypršelo okno, a případně počet resetujete. Pokud počet překročí limit, vrátíte stavový kód 429 a hlavičku s časem, za jak dlouho to zkusit znovu. Pozor na to, že v paměti to funguje jen pro jednu instanci. Jakmile aplikaci škálujete horizontálně, každý proces má vlastní počítadlo a limit se rozplyne. Řešením je sdílené úložiště, typicky Redis, které drží stavy konzistentní.
Kde nejčastěji vzniká zpoždění Největší chybou bývá neoptimalizovaný obrázkový obsah. Fotky v plném rozlišení z foťáku mají klidně několik megabajtů, přitom je zobrazíte v rozměru pár set pixelů. Zmenšete je na cílovou velikost, převeďte do moderního formátu a nastavte atributy šířky a výšky, aby se stránka při načítání neposouvala. U obrázků mimo první obrazovku použijte odložené načítání. Stejný princip platí pro písma: každý řez znamená další požadavek, takže si vystačíte s jedním nebo dvěma řezy a ideálně je hostujte lokálně.
Nejčastější chyby na začátku První chyba je ignorování dokumentace a zkoušení metodou pokus–omyl. API mají pevně dané názvy parametrů a jejich formát. Když pošleš datum v jiném tvaru, než jaký očekává, dostaneš chybu, i když je hodnota věcně správná. Druhá chyba je posílání klíče v adrese. Klíč patří do hlavičky, protože adresy se ukládají do logů a může je vidět někdo, kdo by neměl. Třetí chyba je nulové ošetření chyb. Kód, který předpokládá, že vždy přijde správná odpověď, spadne při první výpadku sítě.
Jakmile zvládneš jedno volání, nauč se číst dokumentaci jako mapu. Hledej sekce o stránkování, limitech a chybových stavech. Tyto tři věci rozhodují o tom, jestli tvá práce obstojí i při větším množství dat. Nezačínej integrací do velkého projektu. Napiš malý skript, který dělá jednu věc, a teprve až funguje spolehlivě, přesuň logiku do zbytku aplikace.
Když něco nefunguje, nehádej. Zkopíruj přesně požadavek, který jsi poslal, a porovnej ho s příkladem v dokumentaci znak po znaku. Většina problémů zmizí, když najdeš překlep v názvu parametru nebo chybějící uvozovky. Pokud jde o ověření, zkontroluj, jestli klíč nevypršel a jestli ho posíláš ve správné hlavičce. U složitějších API se hodí zapnout podrobné logování, aby bylo vidět, co přesně odchází po síti.
U operací, které mění více zdrojů, je potřeba idempotentní klíč kombinovat s optimistickým zamykáním. Například při převodu peněz se kontroluje verze zůstatku. Bez toho může i idempotentní klíč selhat, pokud se mezitím změnil stav. U dlouhých operací se vyplatí oddělit přijetí požadavku od jeho provedení. Server vrátí identifikátor úlohy a klient se dotazuje na stav. Opakované vytvoření úlohy se stejným klíčem vrátí stejný identifikátor.
Než začneš psát kód, zjisti si dvě věci: kde je dokumentace a jestli potřebuješ přístupový klíč. Většina API funguje tak, že pošleš požadavek na konkrétní adresu a dostaneš odpověď ve formátu JSON. Otevři si dokumentaci a najdi sekci, která se jmenuje nějak jako „authentication" nebo „getting started". Tam bývá přesně popsané, jak klíč získat a jak ho posílat. U některých služeb stačí klíč vložit do hlavičky požadavku, jinde se podepisuje každý požadavek zvlášť. To druhé je složitější a pro první pokusy se tomu vyhni.