Nejdřív kritéria, potom nástroje
Debata o technologiích bývá často vedena jako porovnání popularity frameworků. Užitečnější je začít tím, co musí produkt vydržet: jak se mění pravidla, kolik lidí na něm pracuje, jaká data zpracovává a kdo jej bude provozovat. Někde je největší riziko v integraci se starým systémem, jinde v kvalitě mobilního rozhraní nebo v potřebě dohledat rozhodnutí. Různé situace vedou k různým kompromisům, a proto není poctivé doporučovat jeden univerzální stack.
Při výběru zapisujeme několik srovnatelných kritérií: schopnost dodat první hodnotu, bezpečnostní model, předvídatelnost provozu, náklady na změnu, dostupnost odborníků a možnost předání. Technologický experiment má prověřit nejistý bod, nikoli jen ukázat známý příklad z dokumentace. Zvolené řešení má být vysvětlitelné člověku, který bude za systém odpovídat po spuštění. Pokud je rozdíl mezi dvěma možnostmi malý, jednodušší provozní model může být důležitější než teoretická výhoda v benchmarku.
Rozhraní podle uživatelského toku
Frontend se posuzuje podle práce uživatele, ne podle animací v ukázce. Důležité jsou přístupnost, odezva při slabším připojení, čitelnost na mobilu, formuláře s jasnou opravou chyb a stav, který odpovídá skutečnosti v backendu. U redakčního webu navíc záleží na serverově dostupném obsahu, správných adresách a metadatech. U interní aplikace může být zásadnější rychlost práce s tabulkou, klávesnicí a komplikovanými výjimkami.
Volba mezi webem, nativní aplikací a hybridním přístupem se odvíjí od potřeb zařízení, distribučního kanálu, požadavků na offline práci a nákladů na údržbu více platforem. Někdy stačí dobře navržený responzivní web. Pokud mobilní aplikace přidává skutečnou schopnost, měla by mít jasné hranice vůči serveru a pravidla synchronizace. Prototyp se ověřuje na reprezentativních úkolech, ne jen na hlavní obrazovce.
Backend a doménové hranice
Backend potřebuje srozumitelný model pravidel, stavů a oprávnění. Menší produkt může dlouho dobře fungovat jako modulární aplikace s jasnými vnitřními hranicemi. Rozdělení do samostatných služeb dává smysl, když existuje důvod pro oddělené vlastnictví, životní cyklus nebo škálování. Každá síťová hranice zároveň přidává latenci, selhání, verze kontraktů a dohled. Počet služeb proto není měřítkem vyspělosti architektury.
Programovací jazyk se vybírá podle konkrétních požadavků, ekosystému a možnosti údržby. Důležitější než módní syntaktická vlastnost bývá kvalita testů obchodních pravidel, práce s chybou, migrací databáze a pozorovatelností. U důležitých operací je vhodné nakreslit stavový model a vyzkoušet chování při timeoutu či opakování. Pokud tuto logiku neumíme vysvětlit bez kódu, framework ji za nás nezachrání.
Data jako dlouhodobý závazek
Databáze se nevybírá jen podle prvního dotazu. Potřebujeme vědět, co je zdrojem pravdy, jak se data mění, jak se chrání a jak budou obnovena. Relační model může být vhodný pro transakční pravidla a vazby, jiné úložiště pro vyhledávání nebo analytiku. Přidání další databáze však vytváří otázku synchronizace a konzistence. Je proto rozumné začít s nejmenším počtem úložišť, která skutečně řeší rozdílné potřeby.
K migraci dat patří význam polí a historie změn, nikoli pouze export a import souboru. Zkušební obnova zálohy ukáže více než informace, že záloha úspěšně vznikla. Citlivé údaje vyžadují přiměřené oprávnění, retenční pravidla a omezení v logách. U AI se navíc musí ověřit, zda index nebo tréninkový vstup nevytváří novou cestu k obsahu, na který uživatel nemá právo.
Integrace a infrastruktura
Rozhraní mezi systémy potřebuje kontrakt, identifikátory, verze a chování při chybě. HTTP API může být vhodné pro okamžitý dotaz; událost pro práci, která se má dokončit později; dávka pro přenos velkého objemu s tolerovaným zpožděním. Každý mechanismus má jiný způsob opravy. Úspěšný prototyp proto musí ukázat nejen první přenos, ale i opakování, nevalidní vstup a výpadek partnera.
Infrastruktura má odpovídat provozním nárokům. Pro malý web může být Docker Compose na jednom VPS přiměřenější než rozsáhlý cluster, pokud existuje záloha, monitoring, bezpečné aktualizace a plán obnovy. U větší služby mohou požadavky na dostupnost a organizaci práce ospravedlnit více komponent. Rozhodnutí se má opřít o měřitelné limity a odpovědnost týmu, ne o počet nástrojů v architektonickém diagramu.
Jak rozhodnutí zaznamenat
Krátký záznam důležité volby stačí: kontext, zvažované možnosti, důvod, očekávaný přínos a podmínky, za nichž rozhodnutí znovu otevřít. Tím se snižuje riziko, že za rok bude tým opakovat stejnou debatu bez znalosti původních omezení. Technologii lze změnit, když se změní měřené potřeby, ale změna má zahrnout migraci, kompatibilitu a provozní dopad. Vlastník produktu potřebuje rozumět obchodní ceně této změny.
Při poptávce není nutné předepsat celý stack. Užitečnější je poskytnout kritické scénáře, objemy, dostupné systémy, bezpečnostní omezení a vlastní kapacitu pro provoz. Dodavatel by měl umět srovnat varianty a vysvětlit, co by v konkrétní situaci nevolil. Takový rozhovor je lepším důkazem technického úsudku než dlouhá tabulka log a certifikátů bez vazby na skutečný produkt.