Az integráció rejtett költsége

Beszéljünk arról, ami minden fejlesztőt frusztrál, aki komolyan próbált webalkalmazást építeni: az integráció rejtett adója.

Ismered az érzést. Kiválasztottad a szerver frameworköt, az ORM-t, a validációs könyvtárat, a frontendet, a build eszközt. Minden jól néz ki a papíron. Aztán elkezdesz valódi funkciókat építeni, és kiderül, hogy a validációs könyvtár nem érti igazán az ORM visszaadott adatstruktúráját. A frontend framework server-side renderelése nem fér össze a szerver middleware-jával. A session kezelés olyan feltételezésekkel él, amik elromlanak, amikor edge-re próbálod deployolni.

Mindegyik eszköz önmagában kiváló. Az illesztéseknél kezdődik a rémálom.

Hogyan jutottunk ide?

A JavaScript ökoszisztéma mindig a kompozálhatóságot favorizálta a kohézió helyett. Ez nem feltétlenül rossz — a UNIX filozófia évtizedek óta jól szolgál minket. A probléma az, hogy a webalkalmazások nem izolált adattranszformációs pipeline-ok. Összegubancolódott hálók shared assumptions-ekből: request struktúrák, validációs határok, autentikációs folyamatok, renderelési kontextusok, deployment célpontok.

Amikor 2005-ben megjelent a Django, egy fogadást kötött: a fejlesztők cserébe adják a rugalmasságot egy koherens rendszerért. Még mindig ki lehetett nyúlni a stacken kívülre, ha kellett, de belül minden úgy volt megtervezve, hogy együtt működjön. Ez a tulajdonosi szemlélet kevesebb meglepetést jelentett.

A PHP frameworkök is értették ezt. A Laravel, a Symfony, a Yii — mindegyik ugyanazt a "egy koherens rendszer" érzést adta. Tudtad, mi az officiális terület, és mi az, ahova kalandozni kell.

Aztán a JavaScript megette a szervert, és nagyjából elvesztettük ezt.

A Meta-Framework Csapda

A modern meta-frameworks javítottak néhány dolgon. A Next.js, a Nuxt, a SvelteKit — újra adtak egy koherens stacket. De úgy csinálták, hogy leszűkítették a választási lehetőségeidet, nem pedig bővítették.

Ezt úgy értem: a Next.js egy remek React stack. De ha beleszeretsz a Solid teljesítményébe vagy a Svelte egyszerűségébe, nem cseréled le egyszerűen a view layert. Egy másik meta-frameworköt adoptálsz, más konvenciókkal, más routing mintákkal, más backend feltételezésekkel. Újra megtanulod ugazazokat a problémákat, amiket már megoldottál — csak más szintaxissal.

Ez abszurd helyzetet teremt. A frontend ökoszisztéma folyamatosan innovál, de a megközelítések közötti váltáshoz szinte újra kell kezdeni. A React fejlesztők és a Svelte fejlesztők egymástól függetlenül, picit másképp oldják meg uganazokat a backend problémákat, örökké.

A Runtime Lottó

És akkor ott a runtime fragmentáció. A Node.js, a Deno, a Bun — mind képes platformok, de a legtöbb framework gyakorlatilag runtime-specifikus. Amikor egy framework Deno támogatást hirdet, az gyakran csak annyit jelent, hogy "a Deno tudja futtatni a Node kódunkat." Ez nem ugyanaz, mint ha a framework a Deno natív API-jai és execution modellje köré lenne tervezve.

Ez fontosabb, mint amilyennek tűnik. A választott runtime befolyásolja a teljesítmény jellemzőket, a deployment célpontokat és a biztonsági modelleket. Ha olyan frameworkbe zárkózol, ami csak egy runtime-on működik igazán, az korlátozza a lehetőségeidet, ahogy az ökoszisztéma fejlődik.

Amire Valójában Szükségünk Van

A lényeg: a webalkalmazásoknak természetes rétegei vannak, amiknek nem kellene össze lenniük kapcsolva.

A frontendek böngésző UI-t írnak le. A backendek request-eket, adatokat és alkalmazáslogikát kezelnek. A runtime-ok execution célpontok. Ezeknek a concernöknek egymástól függetlenül kellene tudniuk változni.

Képzeld el: az egyik route-ot React-tel építed, mert szükséged van az ecosystemjére. A másikat Svelte-tel, mert ott fontosabb a teljesítmény. A Node.js route-okat ma futtatod, de a TypeScript route-okat Bun-ra deployolod, amikor kell a sebesség. Mindezt ugyanabban az alkalmazásban, ugyanazzal a backend modellel, ugyanazzal a validációval, ugyanazzal a session kezeléssel.

Ez nem varázslat. Ez az, hogy a concernöket külön concernökként kezeljük — és így épül a jó szoftver mindig is.

A Frameworknek Kellene Birtokolnia az Illesztéseket

Nem azért érvelek, hogy egy framework uraljon mindent. azért érvelek, hogy egy frameworknek felelősséget kell vállalnia azért, hogy a darabjai együtt működjenek. Még mindig ki kell tudnod nyúlni az officiális stacken kívülre, ha kell — senki sem szállít tökéletes defaultokat minden use case-re. De amikor a frameworken belül maradsz, az illesztések legyenek a framework problémái, ne a tiéd.

Egy framework, ami miatt a routing, validáció, data access és renderelés külön problémákként gondolkodtat, amiket neked kell összeragasztani — az nem framework. Az egy javaslat.

A legjobb frameworkök a business logic tulajdonlását adják neked, miközben minden mást ők birtokolnak.

A NameOcean-nál láttuk, hogyan szorzódhat meg a hosting komplexitása, ha a stacked fragmentált. Olyan frameworköt választani, ami tiszteletben tartja a concernök szétválasztását — ami lehetővé teszi, hogy darabokat cserélj anélkül, hogy mindent újraírnál — drámaian egyszerűbbé teszi a deploymentet, a skálázást és a karbantartást.

A kérdés nem az, hogy használj-e frameworköt. Az, hogy a frameworkod dolgozik-e érted, vagy csak egy újabb döntésréteget ad hozzá, amire nem volt szükséged.

Mit jelentene a következő alkalmazásodat olyan eszközzel építeni, ami birtokolja az illesztéseket? Érdemes ezen gondolkodni, mielőtt scaffoldolni kezded a következő projektet.