A WebCatalognál évekig a Vercel volt az alapértelmezett hely, ahová szinte mindent telepítettünk, ami a weben futott. Ezeknek a projekteknek a többsége Next.js-t használt, így a párosítás kézenfekvő volt. A marketingoldalaink, a termékfelületeink, a fiókbeállítások, a fejlesztői konzol, a hitelesítés, az adminisztrációs eszközök és az API-k is nagyjából ugyanarra a technológiai alapra kerültek.
Ez sokáig jól működött. A Vercel egyszerűvé tette a telepítést, a Next.js hatékony full-stack keretrendszert adott, és ritkán kellett foglalkoznunk a mögöttük lévő infrastruktúrával.
Idővel azonban ez a kényelem már nem illett a termékeink igényeihez.
A marketingoldalainknak továbbra is hasznára vált az SSR (szerveroldali renderelés), de a többi webalkalmazásunk többségének nem volt rá szüksége. Ezek egyszerű SPA-k (egyetlen oldalból álló alkalmazások) is lehettek. Az API-jainknak hagyományos Node.js-környezetre volt szükségük natív függőségekkel és hosszan futó folyamatokkal. A frontend technológiai alapunkban szinte minden más már Vite-ot használt. Eközben az infrastruktúra költségeit is egyre nehezebb volt figyelmen kívül hagyni, különösen a nyilvános és az automatizált forgalom növekedésével.
Eleinte a meglévő rendszer optimalizálásával próbálkoztunk. Fontolóra vettük, hogy megtartjuk a Next.js-t, és egy adapter segítségével Cloudflare Workersre költöztetjük. Kipróbáltuk az Astrót a marketingoldalakhoz. Rövid időre az API-jainkat is Cloudflare Containersre tettük.
Végül egy egyszerűbb felállásnál kötöttünk ki: a legtöbb webalkalmazásunk ma Vite-ot és TanStack Routert használ Cloudflare Workersön, a marketingoldalaink TanStack Startot használnak SSR-rel Cloudflare Workersön, az API-jaink pedig Hono és tRPC alapokon, hosszan futó Node.js-konténerekként működnek a Railwayen.
A migráció nagyjából 80%-kal csökkentette a webes infrastruktúránk költségeit. Miután szigorítottuk a Cloudflare biztonsági szabályait, és több rosszindulatú automatizált forgalmat blokkoltunk a hálózat peremén, a teljes megtakarítás körülbelül 90%-ra nőtt.
A migráció megvalósításának nagy részét AI-kódoló ügynökök végezték, elsősorban a Claude Fable 5 és a Claude Opus 5. A mérnökök döntöttek az architektúráról, meghatározták a követelményeket, áttekintették a változtatásokat és ellenőrizték az eredményt.
Nem a Vercel elhagyásával kezdtük
Elsőként a meglévő rendszer optimalizálására törekedtünk.
A webcatalog.io volt a legkézenfekvőbb kiindulópont, mert sok nyilvános forgalmat kap, miközben oldalainak többsége viszonylag ritkán változik. Azt tapasztaltuk, hogy a webhely túl nagy részét továbbra is dinamikusan rendereltük. Ezért megszüntettük a véletlenül dinamikussá vált renderelést, ISR-t (inkrementális statikus újragenerálást) vezettünk be a nagy forgalmú útvonalakon, több oldalt tettünk gyorsítótárazhatóvá, és optimalizáltuk az erőforrás-igényes webhelytérkép-kezelést.
A munka segített, de az alapvető problémát is világosabbá tette. Egyre több időt töltöttünk annak megértésével, hogy egy viszonylag statikus tartalom miért dinamikus, melyik keretrendszerbeli működés okozta ezt, és milyen keretrendszerbeli eszközt kell bevezetnünk ahhoz, hogy ismét gyorsítótárazható legyen.
Eközben sok más alkalmazásunknál éppen az ellenkezője volt a helyzet. A fiókbeállításoknak, a fejlesztői konzolnak, az adminisztrációs alkalmazásoknak és a legtöbb termékfelületnek egyáltalán nem kellett szerveroldali renderelés. Ezek böngészőben futó, API-kkal kommunikáló alkalmazások voltak.
Ekkor a kérdés már nem az volt, hogy „Hogyan csökkentsük a Vercel-számlánkat?”, hanem az, hogy „Mit építenénk, ha ezek az alkalmazások nem eleve Next.js-alkalmazások lennének?”
Megfontoltuk a Next.js futtatását Cloudflare-en
A legkevésbé felforgató megoldás az lett volna, ha megtartjuk a Next.js-t, és a Vercelről Cloudflare Workersre költöztetjük.
Komolyan fontolóra vettük ezt, mert adaptereken keresztül a Next.js futtatható Cloudflare-en, így az alkalmazások meglévő szerkezetének nagy részét megőrizhettük volna.
A Cloudflare-en futó Next.js-t azonban nem tekintettük egyenértékűnek a Vercelen futó Next.js-szel. A Next.js a Vercel futtatókörnyezetéhez, telepítési rendszeréhez, gyorsítótárazási működéséhez és platformfunkcióihoz illeszkedik a legszorosabban. Cloudflare-en egy adapternek kell ezeket a feltételezéseket egy másik futtatókörnyezetre lefordítania.
Ez jól működhet, de ha a célunk a technológiai alap egyszerűsítése volt, egy újabb kompatibilitási réteg bevezetése nem tűnt ideálisnak.
Volt egy tágabb eszközkészlettel kapcsolatos kérdés is. Szinte minden más, amit frontend oldalon építettünk, már Vite-ot használt: az asztali alkalmazások, a böngészőbővítmények, az SPA-k és más kliensoldali projektek.
A Next.js erősen a Turbopack felé mozdult el, és a Turbopack sokat fejlődött. Nem a teljesítményével volt gondunk. Számunkra a nagyobb különbséget az ökoszisztéma jelentette. A Vite már eleve közös alap volt a frontend kódbázisunk nagy részében, szélesebb bővítmény-ökoszisztémával és a projektek között jobban újrahasznosítható konfigurációval.
A Next.js megtartása Cloudflare-en tehát a tárhelyszolgáltatási probléma egy részét megoldotta volna, de a keretrendszerek közötti eltérést és a különálló buildeszköz-ökoszisztémát is megőrizte volna.
Ezért hátraléptünk, és megvizsgáltuk, mire van ténylegesen szüksége az egyes feladatoknak.
A feladatok szerint választottuk szét a technológiai alapot
Amint felhagytunk azzal, hogy egyetlen univerzális Next.js-helyettesítőt keressünk, az architektúra sokkal egyszerűbbé vált.
A marketingoldalainknak szükségük volt SSR-re, mert nyilvános, lokalizált oldalaik, metaadataik, kanonikus URL-jeik és webhelytérképeik vannak, és keresőmotorokból is érkezik rájuk forgalom.
A legtöbb más webalkalmazásunknak nem volt szüksége SSR-re: egyszerű Vite-alkalmazások lehettek TanStack Routerrel.
Az API-jainknak egyáltalán nem kellett React-keretrendszer; jobban illett hozzájuk egy hagyományos Node.js-futtatókörnyezet.
A végső felosztás így nézett ki:
Webalkalmazások
Vite + TanStack Router
│
└── Cloudflare Workers
Marketingoldalak
TanStack Start + SSR
│
└── Cloudflare Workers
API-k
Hono + tRPC
│
└── Railway / Node.js-konténerek
Az alapelv egyszerű lett: ott használjunk SSR-t, ahol valódi értéket ad; ahol nem, ott elég egy egyszerű SPA; a háttérszolgáltatásokat pedig háttérszolgáltatásokhoz való futtatókörnyezetben futtassuk.
A legtöbb webalkalmazás SPA lett
Az SPA-kra való átállás volt a legegyszerűbb rész.
A WebCatalog webalkalmazása különösen gyorsan költözött: elkészítettük a Vite-ra és TanStack Routerre épülő új alkalmazás vázát, átvittük a felületet, a telepítést Cloudflare Workersre állítottuk át, és még aznap délelőtt eltávolítottuk a régi Next.js-verziót.
Ugyanezt a mintát követtük a Lexibird webalkalmazásánál, a fiókbeállításoknál, a fejlesztői konzolnál, a hitelesítésnél és az adminisztrációs alkalmazásoknál. Az első SPA vázának elkészítésétől az utolsó Next.js-alkalmazás törléséig körülbelül 19 nap telt el.
Ezeknél az alkalmazásoknál a Cloudflare Workers szerepe szándékosan egyszerű. A Vite statikus állományokat épít, a Cloudflare kiszolgálja őket, az alkalmazás útvonalai pedig szükség esetén az index.html-re esnek vissza. Nincs SSR-futtatókörnyezet, mert semmit nem kell szerveroldalon renderelni.
A nehezebb feladat az volt, hogy megőrizzük az alkalmazások körül idővel kialakult működést. A hitelesítési logika egy részét át kellett helyeznünk a Next.js szerveroldali útvonalaiból az API-ba, és a WebCatalog asztali alkalmazásának régebbi verziói továbbra is olyan régi végpontokra támaszkodtak, amelyek működését fenn kellett tartanunk.
A React-felület áthelyezése könnyű volt.
A meglévő működési szerződések megőrzése nehezebb.
Kipróbáltuk az Astrót, majd öt nap múlva töröltük
A marketingoldalak nehezebbnek bizonyultak.
Elsőként az Astrót választottuk. Természetes választásnak tűnt a webcatalog.io és a lexibird.com számára, mert mindkettő nyilvános, tartalomban gazdag webhely, az Astro pedig jól integrálódik a Cloudflare-rel.
Elkezdtük mindkét webhely átültetését, majd öt nappal később leálltunk.
Nem volt egyetlen végzetes hiba. Ehelyett apró illeszkedési problémák halmozódtak fel. Egyes útvonalaknak az előzetes renderelés során adatbázis-hozzáférésre volt szükségük, miközben a buildkörnyezetünkben szándékosan nem voltak éles adatbázis-hozzáférési adatok. A React-islandek mellett kevésbé volt természetes a megosztott alkalmazásállapot kezelése. Az előre renderelt és a futásidőben renderelt útvonalak közötti eltérésekbe is beleütköztünk, és a repónkban néhány eszközzel is nehézségek adódtak.
Ezek közül egyik probléma sem volt megoldhatatlan. Éppen ezért lett volna veszélyes folytatni: könnyen eltölthettünk volna még néhány hetet azzal, hogy sorra javítjuk őket.
Ehelyett töröltük a megvalósítást, és újrakezdtük.
Az AI-ügynökök megváltoztatták ennek a döntésnek a gazdasági oldalát. A mechanikus átültetés nagy része nem emésztett fel heteket a mérnökök idejéből, ezért kisebb volt a már befektetett munka értéke, és könnyebb volt elismerni, hogy más architektúrát részesítünk előnyben.
A TanStack Start jobban illett hozzánk
A marketingoldalak migrációját az eredeti Next.js-kódból indítottuk újra, ezúttal TanStack Starttal.
Sokkal természetesebben illeszkedett, mert az SPA-alkalmazásokban már TanStack Routert használtunk, így az útválasztás, a loaderek, a keresési paraméterek és a navigáció hasonló elveket követett. A kód továbbra is hagyományos React és TypeScript maradt, a buildrendszer pedig Vite volt.
A lexibird.com-ot egy nap alatt átültettük TanStack Startra. Ezt követte a webcatalog.io.
Nem arról volt szó, hogy a TanStack Start varázsütésre minden problémát megoldott. Az volt az előnye, hogy illett ahhoz az irányhoz, amerre a technológiai alapunk többi része már tartott.
Egy monorepóban ez számít. A közös buildeszközök révén több bővítmény és konfiguráció használható újra, kevesebb a különleges eset hibakereséskor, a fejlesztőknek ritkábban kell eltérő rendszerek között váltaniuk, és a kódoló ügynököknek is kevesebb projektspecifikus konvenciót kell felfedezniük.
A Cloudflare a mi forgalmunkhoz sokkal olcsóbb volt
A számlánk csökkenésének csak egyik oka volt az architektúra. A Cloudflare árazása jelentős tényező volt, különösen a sávszélesség terén.
A Cloudflare Workers fizetős csomagjában a díjazás jelenleg elsősorban a kéréseken és a CPU-használaton alapul; a Workers esetében nem számítanak fel külön adatátviteli vagy sávszélességi díjat. (developers.cloudflare.com) Ez sokat számít a nyilvános webhelyeknél, mert egy kérés nagyon kevés CPU-t használhat, miközben HTML-t, JavaScriptet, képeket, betűkészleteket és más állományokat továbbít.
A Vercel árazási modelljében a hálózati használathoz kapcsolódó kategóriák és keretek is szerepelnek, köztük a Fast Data Transfer és a Fast Origin Transfer. (vercel.com) A mi forgalmi profilunk mellett a Cloudflare költségei lényegesen kedvezőbbek voltak.
A megtakarítás nem kizárólag a szolgáltatóváltásból származott. Sok alkalmazást statikus Vite-buildekre állítottunk át, csökkentettük a szükségtelen SSR-t, egyértelműbbé tettük a gyorsítótárazást, és az API-kat a számukra megfelelőbb futtatókörnyezetbe költöztettük. A Cloudflare árazása, különösen a sávszélesség tekintetében, mégis jelentősen hozzájárult a megfigyelt, nagyjából 80%-os csökkenéshez.
Ez a szám a mi terhelésünkre vonatkozik. Nem állítjuk, hogy minden alkalmazás 80%-ot takarít meg, ha Vercelről Cloudflare-re költözik.
Az API-k végül a Railwayre kerültek
Az API-k külön problémát jelentettek.
Bár Next.js-projektek voltak, már nagyrészt függetlenek voltak a Next.js-től. A WebCatalog API-ja körülbelül 34 000 sorból állt, de csak hét fájl importálta a next/server modult. A tRPC már a Fetch adapterét használta, az Inngest pedig támogatta a Honót.
A Next.js-alapú HTTP-réteget Honóra cseréltük. Ez meglepően kis munka volt.
A nehezebb kérdés az volt, hogy hol futtassuk. A hagyományos Workers nem volt jó választás, mert az API-k Node.js-t és natív függőségeket, például a sharp csomagot használnak.
Először a Cloudflare Containerst próbáltuk ki, amellyel gyorsan el tudtunk jönni a Vercelről. Miután azonban éles környezetben is futtattuk, kiderült, hogy az üzemeltetési modell több kézi kapacitáshangolást igényel, mint amennyit akkor szerettünk volna.
Ezért újra átköltöztettük az API-kat.
Ma a Railwayen futnak hagyományos, hosszan élő Node.js-konténerszolgáltatásokként. A CI (folyamatos integráció) Docker-képeket épít, feltölti őket a képtárunkba, a Railway pedig gondoskodik a horizontális automatikus skálázásról.
Nem kell mindennek a hálózat peremén futnia.
A Vercel elhagyásával több felelősséget vállaltunk
Az alacsonyabb költség kompromisszummal járt.
A Vercel és a Next.js sok infrastrukturális működést magasabb szinten kezelt. A TanStack Start és a Workers használatával inkább az explicit HTTP-gyorsítótárazás felé mozdultunk el. Az oldalt rendereljük, gyorsítótárazási fejlécekkel küldjük vissza, a Cloudflare pedig gyorsítótárazza a választ. A böngészőben és a hálózat peremén eltérő gyorsítótárazási szabályok érvényesülhetnek, beleértve a peremhálózaton az elavult tartalom kiszolgálását az újraérvényesítés ideje alatt.
Szerettük, hogy ezek a döntések egyértelművé váltak, de ha magunk kezeljük az infrastruktúrát, a hibákért is mi felelünk.
El is követtünk néhányat. Egy éles gyorsítótárazási szabály véletlenül az egyes látogatókhoz kötődő TanStack-szerverfüggvények válaszaira is illeszkedett, egy másik gyorsítótárazási beállítás pedig rosszul működött együtt az SPA tartalék útvonalkezelésével. Ezek a hibák hasznos emlékeztetők voltak arra, hogy a migráció helyességét nem lehet kizárólag a repó alapján bizonyítani. Az éles infrastruktúra is a rendszer része.
Az AI-ügynökök megváltoztatták a migráció módját
A megvalósítás nagy részét kódoló ügynökök végezték, elsősorban a Claude Fable 5 és a Claude Opus 5.
A keretrendszerek közötti migráció különösen jól illik az ügynökökhöz, mert a munka nagy részéhez egyértelmű, meglévő referencia áll rendelkezésre. Helyezd át ezt az útvonalat, őrizd meg ezt az URL-t, cseréld le ezt a keretrendszer-API-t, tartsd meg ugyanazokat a metaadatokat, futtasd a típusellenőrzést, javítsd ki a hibákat, és hasonlítsd össze az eredményt a régi megvalósítással.
A webcatalog.io-hoz migrációs feladatkövetőt vezettünk, amely a munkát olyan szakaszokra bontotta, mint az alapok, a termékoldalak, a katalógusoldalak, a keresés, a blog, az árak, az átirányítások, a webhelytérképek és az átállás. Ahelyett, hogy azt kértük volna egy ügynöktől, hogy „költöztesd át a webcatalog.io-t TanStack Startra”, jól körülhatárolt feladatokat adtunk neki, egyértelműen megfogalmazott, megőrzendő követelményekkel.
A meglévő alkalmazás lett a specifikáció. Az ügynök feladata az volt, hogy az új architektúrában reprodukálja a működést, nem pedig az, hogy újratervezze a terméket.
Így az emberi munka súlypontja a kód kézi átültetéséről olyan kérdésekre helyeződött át, mint hogy valóban kell-e SSR az adott oldalhoz; mely működés szándékos; mit lehet mindenki számára közösen gyorsítótárazni; mely URL-eknek kell változatlannak maradniuk; hol történjen a hitelesítés; és mikor kell felhagyni egy megközelítéssel.
Az eredményt továbbra is átnéztük, futtattuk a buildeket és a típusellenőrzést, valamint kézzel ellenőriztük a nagyobb kockázatú területeket, például a hitelesítést, a SEO-t (keresőoptimalizálást), az átirányításokat és a gyorsítótárazást.
A lényeges változás nem az volt, hogy az AI kódot írt helyettünk. Hanem az, hogy olcsóbbá tette a kísérletezést.
Így sokkal könnyebb volt indokolni, hogy kipróbáljuk az Astrót, majd öt nap után töröljük a megvalósítást. Kevésbé volt fájdalmas egyszer átköltöztetni az API-kat, majd úgy dönteni, hogy egy másik platform jobban megfelel. A mechanikus munka olcsóbbá vált, ezért irányt válthattunk, amikor az architektúra nem volt megfelelő, ahelyett hogy csak azért folytattuk volna, mert már túl sokat fektettünk bele.
Az ügynököknek köszönhetően a megvalósításra fordítható kapacitás kevésbé volt szűkös.
Ez még fontosabbá tette az architektúrát, a követelmények meghatározását, az áttekintést és az ellenőrzést.
A 80%-ból nagyjából 90% lett
A migráció után a webes infrastruktúránk költsége nagyjából 80%-kal alacsonyabb volt.
Ezután jobban odafigyeltünk arra, hogy egyáltalán mely kérések jutnak el az alkalmazásokig.
A nyilvános internetes forgalom számottevő része automatizált: keresőmotorok, AI-feltérképezők, ügynökök, adatgyűjtő robotok, szkennerek és kevésbé barátságos botok generálják. A forgalom egy része hasznos, más része nem.
Mivel az alkalmazások közvetlenül a Cloudflare mögött futottak, szigorítottuk a biztonsági szabályainkat, hogy a rosszindulatú automatizált forgalmat már a hálózat peremén elutasíthassuk, mielőtt alkalmazásszintű számítási vagy adatbázis-műveletet váltana ki.
Ezt követően a teljes megtakarításunk a régi rendszerhez képest nagyjából 90%-ot ért el.
A végső csökkenést több tényező együttesen eredményezte: a Cloudflare alacsonyabb árai, különösen a sávszélesség terén; a kevesebb szerveroldali munka; az API-jainknak jobban megfelelő futtatókörnyezet; az egyértelműbb gyorsítótárazás; és az, hogy kevesebb fölösleges kérés jutott el egyáltalán az alkalmazásokig.
Hová jutottunk
A repónkban már nem maradt Next.js-alkalmazás. A legtöbb webalkalmazásunk ma Vite-ra és TanStack Routerre épülő SPA Cloudflare Workersön. A webcatalog.io és a lexibird.com TanStack Startot használ Cloudflare Workersön, mert ezeknek a webhelyeknek valóban hasznára válik az SSR. Az API-jaink Honót és tRPC-t használnak a Railwayen, hagyományos Node.js-konténerekben futva. Szinte minden frontend projektünk ma már a Vite-ökoszisztémához tartozik.
Az infrastruktúránk költsége nagyjából 80%-kal csökkent. Ehhez jelentősen hozzájárult, hogy a Cloudflare árazása a mi forgalmunk mellett sokkal kedvezőbb, különösen a sávszélesség tekintetében. A rosszindulatú automatizált forgalom kiszűrése a hálózat peremén az összesített megtakarítást körülbelül 90%-ra növelte.
Számunkra azonban az architekturális eredmény a legfontosabb. A marketingoldalak SSR-t kapnak, minden más, ami lehet SPA, SPA-ként működik, az API-k pedig valódi szervereken futnak, amikor ez az egyszerűbb megoldás.
Azzal kezdtük, hogy olcsóbbá próbáltuk tenni a Vercelt.
Végül rájöttünk, hogy annak az architektúrának a nagy részére, amelyért fizettünk, nincs is szükségünk.