
Next.js vs htmx + Rust. Čo použiť a kedy
Porovnajte Next.js s Axum, Askama a htmx podľa stavu v prehliadači, kontraktov, cache, nasadenia, bezpečnosti, mobilných klientov a odovzdania.

Návrhový vzor nie je známka seniority. Je to pomenovanie riešenia, ktoré sa opakovane osvedčilo pri určitom druhu problému. Ak problém ešte nemáte, vzor Vám nepomôže. Pridá iba nové súbory, rozhrania a názvy, cez ktoré sa musí ďalší človek prehrýzť.
Pri návrhu firemného softvéru sa preto nepýtam, ktorý vzor by sa dal použiť. Pýtam sa, ktorá časť sa bude meniť, kto ju mení a čo pritom musí zostať stabilné. Až odpoveď ukáže, či potrebujeme Strategy, Adapter, Factory alebo obyčajnú funkciu.
Rozhodujte podľa zmeny, nie podľa názvu vzoru
Najmenšia abstrakcia, ktorá izoluje pravdepodobnú zmenu, býva správna.
Jedno stabilné pravidlo
Ponechajte priamu funkciu.
Meniteľný algoritmus
Zvážte Strategy.
Cudzie rozhranie
Izolujte ho Adapterom.
Viac spôsobov vytvorenia
Factory môže skryť zostavenie.
Predstavte si výpočet ceny dopravy. Prvá verzia podporuje osobný odber a jedného kuriéra. Dve podmienky v jednej funkcii sú v tejto chvíli čitateľnejšie než strom tried. Každý vidí vstup, pravidlo aj výsledok.
Problém vznikne až vtedy, keď sa pravidlá začnú meniť nezávisle. Kuriér má inú cenu podľa hmotnosti, ďalší podľa regiónu a firemní zákazníci majú vlastnú zmluvu. Jedna funkcia potom pozná príliš veľa dôvodov na zmenu. Úprava pre jedného dopravcu môže poškodiť ostatných.
Dobrý návrh nereaguje na počet riadkov. Reaguje na počet nezávislých dôvodov, pre ktoré sa kód mení. Päťdesiat stabilných riadkov môže byť jednoduchších než desať riadkov, ktoré každý týždeň upravujú tri rôzne tímy.
Strategy sa hodí, keď máme jednu úlohu a viac zameniteľných spôsobov, ako ju vykonať. Výpočet dopravy zostáva tou istou úlohou. Mení sa algoritmus podľa dopravcu alebo zmluvy.
type DeliveryQuote = (order: Order) => Money;
const quoteDelivery = (
order: Order,
quote: DeliveryQuote
): Money => quote(order);
Strategy nemusí byť trieda. V TypeScripte často stačí typ a niekoľko čistých funkcií. Dôležité je, že objednávka nepozná cenník kuriéra a cenník nemusí vedieť, odkiaľ objednávka prišla. Nové pravidlo pridáme bez zásahu do existujúcich algoritmov.
Vzor sa neoplatí, ak existuje jeden stabilný výpočet alebo ak varianty zdieľajú väčšinu komplikovaného stavu. Vtedy môžu malé stratégie iba presúvať podmienky medzi súbormi. Najprv treba pomenovať skutočnú hranicu.
Integrácia ERP, platobnej brány alebo prepravcu prináša cudzie názvy, dátové typy a chybové stavy. Ak ich pustíme priamo do jadra aplikácie, doména začne hovoriť jazykom dodávateľa. Zmena API potom zasiahne objednávky, faktúry aj používateľské rozhranie.
Adapter preloží cudzie rozhranie do malého kontraktu, ktorému rozumie náš systém. Doména môže žiadať reserveStock, aj keď jedno ERP používa skladové pohyby a druhé rezervácie položiek. Rozdiel zostáva v integračnej vrstve.
Takáto hranica pomáha aj pri testovaní. Doménový test nepotrebuje sieť ani sandbox dodávateľa. Overí správanie proti vlastnému kontraktu. Samostatný integračný test potom dokazuje, že adapter správne prekladá požiadavku a odpoveď.
Adapter nie je miesto, kam schováme ľubovoľný neporiadok. Ak iba premenúva každé pole jedna k jednej a dodávateľské API je stabilné, môže byť zbytočný. Jeho hodnota rastie s rozdielom medzi cudzím modelom a našou doménou.
Factory rieši vytváranie objektu alebo pracovného toku, keď zostavenie závisí od typu vstupu. Spracovanie PDF faktúry môže potrebovať OCR, validátor fakturačných údajov a účtovný mapper. Zmluva použije iný extraktor a inú sadu kontrol.
Volajúci nemá poznať poradie všetkých závislostí. Požiada o procesor pre konkrétny typ dokumentu. Factory ho zostaví a vráti cez spoločný kontrakt.
Obchodné rozhodnutie však nemá zmiznúť v obrovskej Factory s desiatkami vetiev. Výber podľa typu dokumentu patrí k vytvoreniu. Rozhodnutie, či sa faktúra smie automaticky zaúčtovať, patrí do doménového pravidla a musí zostať viditeľné a testovateľné.
Rovnaká funkcia, iné miesto zmeny
Vzory majú zmysel vtedy, keď zmenšia dosah ďalšej reálnej úpravy.
Predtým
Jedna služba pozná ceny, dodávateľov aj formáty dokumentov.
Po rozdelení
Doména volá malé rozhranie a detail zmeny zostáva za hranicou.
Pri review si kladieme tri otázky. Vieme pomenovať konkrétnu očakávanú zmenu? Zostane po zavedení vzoru táto zmena za jednou hranicou? Je výsledok čitateľnejší pre človeka, ktorý nepozná históriu rozhodnutia?
Ak je odpoveď nie, abstrakcia pravdepodobne prišla priskoro. Kód nemusí byť pripravený na každú predstaviteľnú budúcnosť. Má byť pripravený na zmeny, ktoré vyplývajú z produktu, zmlúv a prevádzky.
Vzory sa môžu skladať. Adapter dodá doméne jednotné rozhranie, Strategy vyberie pravidlo a Factory zostaví potrebné závislosti. Takáto kombinácia má zmysel iba vtedy, keď každá časť chráni inú hranicu. Ak tri názvy opisujú jednu podmienku, návrh je priveľký.
Majiteľ firmy nepotrebuje kontrolovať diagram tried. Potrebuje vedieť, či nový spôsob platby alebo ďalšie ERP vyžaduje zásah do celého systému. CTO potrebuje vidieť, kde sa pravidlo nachádza, aký má kontrakt a ktorý test chráni správanie.
Pri návrhu softvéru na mieru preto spájame technickú hranicu s reálnou zmenou v podnikaní. Ďalší diel ukazuje, ako rovnaký princíp funguje vo väčšom meradle pri rozhodovaní medzi modulárnym monolitom a mikroslužbami. Ak Vás zaujíma vplyv AI na samotnú vývojársku prácu, pozrite si aj náš článok o človeku v slučke pri AI vývoji.
Najlepší vzor je ten, ktorý po zavedení prestanete vnímať. Ďalšia zmena má jasné miesto, test má jasný dôvod a zvyšok systému o nej nemusí vedieť.
Pred zavedením abstrakcie sa oplatí urobiť malý experiment. Skúste druhý variant napísať priamo a porovnajte dosah zmien v teste aj produkčnom kóde. Ak priama verzia zostane čitateľná, je priskoro pridávať nový pojem. Ak sa rovnaké rozhodovanie opakuje na viacerých miestach, hranica už má merateľný dôvod existovať. Vzor si tak zaslúži miesto výsledkom, nie známym názvom.
Rozhodnutie stručne zapíšte. Stačí problém, očakávaná zmena a dôvod, prečo zvolená hranica pomáha pri ďalšej úprave. Ďalší človek potom vie vzor odstrániť, keď predpoklad prestane platiť.
Maroš Bednár pripravil článok s podporou AI pri rešerši a jazykovej úprave. Odborné závery, príklady a finálny text skontroloval a schválil.

Porovnajte Next.js s Axum, Askama a htmx podľa stavu v prehliadači, kontraktov, cache, nasadenia, bezpečnosti, mobilných klientov a odovzdania.

Kontrolný zoznam pre kupujúceho softvéru. Pokrýva bezpečnosť, integrácie, roly pri dátach, vlastníctvo, podporu a odovzdanie pred podpisom zmluvy.
Praktický návod na požiadavky, porovnanie dodávateľov, overenie dôkazov a spoločné rozhodnutie o technologickom partnerovi.