Proč je integrace pořád takový problém?

Pojďme si promluvit o něčem, co frustrationuje každého vývojáře, který se pokusil nasadit vážnou webovou aplikaci. Říkám tomu neviditelná daň z integrace.

Znáte to pocit. Vybrali jste si server framework, ORM, validační knihovnu, frontend, build tool. Na papíře vše vypadá skvěle. Pak ale začnete stavět reálné funkce a zjistíte, že vaše validační knihovna úplně nerozumí tomu, co vrací vaše ORM. Server-side rendering vašeho frontend frameworku se nesnáší s middleware vašeho serveru. A session handling dělá předpoklady, které se rozbijí, když se pokusíte deployovat na edge.

Každý nástroj samostatně je skvělý. Spoje mezi nimi jsou noční můra.

Jak jsme se sem dostali

JavaScript ekosystém vždycky preferoval composability před cohesion. To není automaticky špatně — UNIX filosofie nám sloužila desítky let. Problém je, že webové aplikace nejsou pipelines izolovaných datových transformací. Jsou to zamotané sítě sdílených předpokladů: tvary requestů, validační hranice, autentikační toky, renderovací kontexty, deployment cíle.

Když přišel Django v roce 2005, vsadil na to, že vývojáři obětovají trochu flexibility výměnou za koherentní systém. Stále jste mohli sáhnout mimo stack, když bylo potřeba, ale uvnitř bylo všechno navržené tak, aby spolupracovalo. Ten ownership znamenal méně překvapení.

PHP frameworky to chápaly taky. Laravel, Symfony, Yii — všechny poskytovaly ten pocit „jeden koherentní systém". Věděli jste, co je oficiální území a co vyžaduje výpravu do divočiny.

Pak JavaScript sežral server a my jsme to většinou ztratili.

Past meta-frameworků

Moderní meta-frameworky to vylepšily — ale jen částečně. Next.js, Nuxt, SvelteKit — daly vám zpátky koherentní stack. Jenže to udělaly tím, že zúžily vaše možnosti, místo aby je rozšířily.

Tady je pointa: Next.js je skvělý React stack. Ale pokud se zamilujete do Solid výkonnostních charakteristik nebo do Svelte jednoduchosti, nemůžete jen tak vyměnit view vrstvu. Přijmete jiný meta-framework s jinými konvencemi, jinými routingovými vzory, jinými backendovými předpoklady. Znovu se učíte stejné problémy, které jste už vyřešili — jen s jinou syntaxí.

Vzniká tady bizarní situace. Frontend ekosystém pořád inovuje, ale přepínání mezi přístupy vyžaduje téměř restart. React vývojáři a Svelte vývojáři řeší stejné backendové problémy nezávisle na sobě, lehce odlišnými způsoby, donekonečna.

Loterie runtime prostředí

A pak je tady fragmentace runtime prostředí. Node.js, Deno, Bun — to jsou všechno schopné platformy, ale většina frameworků je efektivně runtime-specific. Když framework tvrdí „Deno support", často to jen znamená „Deno může spustit náš Node kód." To není totéž jako když je framework navržený kolem nativních Deno API a execution modelu.

To je důležitější, než by se mohlo zdát. Runtime, který si vyberete, ovlivňuje výkonnostní charakteristiky, deployment cíle a security modely. Uzamknout se do frameworku, který skutečně funguje jen na jednom runtime, omezuje vaše možnosti, jak se ekosystém vyvíjí.

Co ve skutečnosti potřebujeme

Tady je pointa: webové aplikace mají přirozené vrstvy, které spolu nemusí být spojené.

Frontendy popisují browser UI. Backendya handlují requesty, data a aplikační logiku. Runtimes jsou execution cíle. Tyto concerns by měly moci varirovat nezávisle.

Představte si, že stavíte jednu route s Reactem, protože potřebujete jeho ekosystém komponent. Další route se Svelte, protože tam záleží víc na výkonu. Vaše Node.js route běží dneska, ale vaše TypeScript route se deployuje na Bun, když potřebujete rychlost. To vše ve stejné aplikaci, se stejným backendovým modelem, stejnou validací, stejnými sessions.

To není magické myšlení. To je zacházení s concerns jako s oddělenými concerns — což je způsob, jakým byl vždycky stavěn dobrý software.

Framework by měl vlastnit spoje

Nehájím jednu framework, aby vládl všem. Hájím to, aby framework přebíral zodpovědnost za to, že jeho části fungují dohromady. Měli byste pořád moci sáhnout mimo oficiální stack, když potřebujete — nikdo neshipuje dokonalé defaulty pro každý use case. Ale když zůstanete uvnitř frameworku, spoje by měly být jeho problém k vyřešení, ne váš.

Framework, u kterého musíte přemýšlet o routování, validaci, přístupu k datům a renderování jako o oddělených problémech, které musíte slepit dohromady, není framework. Je to návrh.

Nejlepší frameworky vám dávají ownership vaší business logiky a zároveň přebírají ownership všeho ostatního.

Na NameOcean jsme viděli, jak se hostingová komplexita násobí, když je váš stack rozdrobený. Vybrat framework, který respektuje separation of concerns — který vám umožní měnit části bez přepisování všeho — dělá deployment, škálování a údržbu dramaticky jednodušší.

Otázka není, jestli používat framework. Otázka je, jestli váš framework pracuje pro vás, nebo jen přidává další vrstvu rozhodnutí, která jste nemuseli dělat.

Co by znamenalo postavit vaši další aplikaci s nástrojem, který vlastní spoje? To stojí za to promyslet, než začnete scaffoldovat další projekt.