Začněte u informační hierarchie. Obrazovka by měla vést oko návštěvníka od nejdůležitějšího prvku k méně důležitým. Hlavní výzvu k akci (například tlačítko pro odeslání formuláře) umístěte do vizuálně exponovaného místa, obvykle do prvního pohledu. Nezahlcujte prostor desítkami barev a kontrastních prvků – pokud je všechno zvýrazněné, nic se nezvýrazní. Pro běžné akce používejte neutrální barvy, pro primární akci sytou, ale ne křiklavou.
Na závěr se zaměřte na dokumentaci. Bez ní je i nejlépe napsané API nepoužitelné. Můžete použít automatické generátory, které vytvoří dokumentaci přímo z kódu, ale i ruční popis hlavních endpointů je lepší než nic. Nezapomeňte na příklady volání a ukázky odpovědí. Kvalitní dokumentace šetří čas vám i vašim kolegům a snižuje počet chyb při integraci. A to je přesně to, o čem REST API v Node.js a Expressu skutečně je.
Poslední, ale zásadní bod: pravidelný bezpečnostní audit kódu. SQL injection se často objeví po refaktoringu, kdy se zdánlivě neškodná změna promění v kritickou chybu. Do vývojového procesu zařaďte code review zaměřené na databázové dotazy a používejte statickou analýzu, která hledá nebezpečné vzory. Starší kód, který vznikl před zavedením bezpečnostních standardů, zkontrolujte prioritně – právě tam se obvykle skrývají nejhorší chyby. Nezapomeňte na pravidelné aktualizace frameworků a knihoven, protože mnoho zranitelností se opravuje právě v nich. Bezpečnost není jednorázový úkol, ale průběžný proces.
Při psaní kódu se zaměřte na vrstvenou obranu. I když používáte parametrizované dotazy, omezte práva databázového uživatele – aplikace by měla mít přístup pouze k nutným tabulkám a operacím. Nikdy nepřipojujte k databázi jako root nebo administrátor. Dalším krokem je validace vstupů na úrovni aplikace, ale ne jako náhrada parametrizace, jen jako doplněk. Například e-mailová adresa by měla projít filtrem, ale stejně by měla být předána přes prepared statement. Pozor také na chybové hlášky – nikdy nevracejte detailní informace o SQL dotazu, protože to útočníkovi usnadní práci. Místo toho použijte generickou chybovou stránku a detaily zapisujte do logu.
Při návrhu REST API v Node.js s Expressem se většina vývojářů soustředí na správné routy, middleware a databázové dotazy. Mnohem méně pozornosti už věnuje konzistenci odpovědí a chybovým stavům. Přitom právě tato oblast rozhoduje o tom, jak dobře bude vaše API použitelné pro frontendové aplikace i třetí strany. Bez jednotné struktury odpovědí se každý nový endpoint stává noční můrou při integraci.
Další past, do které začátečníci spadají, je přeceňování kvantity. Pět mini-projektů z tutoriálů na vašem GitHubu působí dojmem, že jen opisujete cizí kód. Jeden funkční projekt, který sami navrhnete a nasadíte, má desetkrát větší váhu. Nebojte se přiznat, co nefunguje nebo co jste museli přepsat. Firmy oceňují, když vidí vaši schopnost iterovat a zlepšovat se. Právě vaše chyby a jejich oprava jsou to, co vás odliší od stovek dalších uchazečů.
Nakonec myslete na to, že čistý kód je výsledkem neustálé údržby. Když vidíte, že se vám funkce opakují na dvou místech, zobecněte je. Když se vám zdá podmínka příliš složitá, vytáhněte ji do samostatné funkce s výstižným názvem. A pokud se vám zdá, že kód dělá příliš mnoho věcí, rozdělte ho. Pravidlo je jednoduché: kód by měl být čitelný pro kolegu, který na projektu začne pracovat zítra, a pro vás samotné za půl roku. To je důležitější než jakákoli optimalizace výkonu.
Základní princip obrany je jednoduchý – nikdy neskládat SQL dotaz pomocí řetězcové konkatenace. Místo toho používejte parametrizované dotazy, ať už přes PDO, MySQLi, nebo ekvivalentní API ve vašem jazyce. Místo zápisu SELECT * FROM uzivatele WHERE jmeno = ‘$jmeno’ použijte prepared statement, kde se hodnota předává zvlášť. Tím se SQL příkaz oddělí od dat a útočník nemá šanci vložit vlastní kód. Toto pravidlo platí pro všechny databázové operace – nejen pro SELECT, ale i pro INSERT, UPDATE a DELETE. Pokud framework nabízí query builder, použijte ho, ale vždy ověřte, že hodnoty procházejí přes binding, ne přes přímý zápis do SQL řetězce.
Nezapomeňte, že první zaměstnání není o dokonalém kódu, ale o tom, jestli do týmu zapadnete a jestli se rychle učíte. Proto se vyhněte dvěma extrémům: nepřehánějte své zkušenosti a zároveň se nepodceňujte. Když firma hledá juniora, ví, že bude investovat do vašeho rozvoje. Vaším úkolem je ukázat, že tato investice nebude ztracená. Připravte si proto otázky na plat? Ne, to nechte na pozdější fázi. Místo toho se ptejte na mentoring, na to, jak vypadá první měsíc v práci, nebo na to, co by si přáli, abyste se naučil před nástupem.
