Vercel bol celé roky predvolenou platformou, na ktorú sme vo WebCatalogu nasadzovali takmer všetko, čo sme prevádzkovali na webe. Väčšina týchto projektov používala Next.js, takže táto kombinácia bola prirodzená. Naše marketingové stránky, produktové rozhrania, nastavenia účtu, vývojárska konzola, autentifikácia, administračné nástroje aj API tak skončili na približne rovnakom technologickom základe.
Dlho to fungovalo dobre. Vercel zjednodušoval nasadzovanie, Next.js nám poskytoval produktívny full-stack framework a nad infraštruktúrou pod nimi sme sa takmer nemuseli zamýšľať.
Časom však toto pohodlie prestalo zodpovedať tomu, aké naše produkty skutočne boli.
Našim marketingovým stránkam stále prospievalo SSR (renderovanie na strane servera), ale väčšina ostatných webových aplikácií ho nepotrebovala. Mohli byť obyčajnými SPA (jednostránkovými aplikáciami). Naše API potrebovali bežné prostredie Node.js s natívnymi závislosťami a dlho bežiacimi procesmi. Takmer všetko ostatné v našom frontendovom stacku už používalo Vite. Zároveň bolo čoraz ťažšie prehliadať náklady na infraštruktúru, najmä s rastúcou verejnou a automatizovanou návštevnosťou.
Najprv sme sa pokúsili optimalizovať to, čo sme už mali. Zvažovali sme, že si ponecháme Next.js a cez adaptér ho presunieme na Cloudflare Workers. Pre marketingové stránky sme vyskúšali Astro. Na krátky čas sme naše API nasadili na Cloudflare Containers.
Napokon sme skončili pri jednoduchšom riešení: väčšina našich webových aplikácií teraz používa Vite + TanStack Router na Cloudflare Workers, marketingové stránky používajú TanStack Start so SSR na Cloudflare Workers a API používajú Hono + tRPC na Railway ako dlho bežiace kontajnery Node.js.
Migrácia znížila naše náklady na webovú infraštruktúru približne o 80 %. Keď sme potom sprísnili bezpečnostné pravidlá v Cloudflare a začali na okraji siete blokovať viac škodlivej automatizovanej návštevnosti, celková úspora vzrástla približne na 90 %.
Väčšinu implementácie migrácie vykonali aj AI agenti na programovanie, predovšetkým Claude Fable 5 a Claude Opus 5. Inžinieri rozhodovali o architektúre, určovali obmedzenia, kontrolovali zmeny a overovali výsledok.
Nezačali sme odchodom z Vercelu
Našou prvou reakciou bolo optimalizovať existujúce riešenie.
Najzjavnejším miestom, kde začať, bol webcatalog.io, pretože má vysokú verejnú návštevnosť, zatiaľ čo väčšina jeho stránok sa mení pomerne zriedka. Zistili sme, že priveľká časť webu sa stále renderuje dynamicky. Opravili sme preto neúmyselné dynamické renderovanie, na veľmi navštevované cesty pridali ISR (inkrementálne generovanie statických stránok), umožnili ukladanie ďalších stránok do vyrovnávacej pamäte a optimalizovali náročné spracovanie máp stránok.
Táto práca pomohla, no zároveň jasnejšie ukázala základný problém. Čoraz viac času sme trávili zisťovaním, prečo je relatívne statický obsah dynamický, ktoré správanie frameworku to spôsobilo a aký mechanizmus frameworku musíme použiť, aby sa dal opäť ukladať do vyrovnávacej pamäte.
Mnohé naše ďalšie aplikácie pritom mali opačný problém. Nastavenia účtu, vývojárska konzola, administračné aplikácie a väčšina produktových rozhraní nepotrebovali renderovanie na serveri vôbec. Boli to aplikácie bežiace v prehliadači, ktoré komunikovali s API.
V tej chvíli sa otázka zmenila z „Ako znížime účet za Vercel?“ na „Čo by sme vytvorili, keby tieto aplikácie už neboli aplikáciami Next.js?“
Zvažovali sme Next.js na Cloudflare
Najmenej rušivou možnosťou bolo ponechať Next.js a presunúť ho z Vercelu na Cloudflare Workers.
Túto možnosť sme vážne zvažovali, pretože Next.js môže na Cloudflare bežať prostredníctvom adaptérov, čo by nám umožnilo zachovať veľkú časť existujúcej štruktúry aplikácií.
Next.js na Cloudflare sme však nepovažovali za ekvivalent Next.js na Verceli. Next.js je najtesnejšie integrovaný s runtime prostredím, systémom nasadzovania, správaním vyrovnávacej pamäte a funkciami platformy Vercel. Na Cloudflare musí adaptér tieto predpoklady preniesť do iného runtime prostredia.
Môže to fungovať dobre, ale ak sme chceli stack zjednodušiť, pridanie ďalšej kompatibilnej vrstvy sa nám nezdalo ideálne.
Bol tu aj širší problém s nástrojmi. Takmer všetko ostatné, čo sme vyvíjali pre frontend, už používalo Vite: desktopové aplikácie, rozšírenia prehliadača, SPA aj ďalšie projekty bežiace na strane klienta.
Next.js sa výrazne priklonil k Turbopacku a Turbopack sa veľmi zlepšil. Nešlo o výhradu k výkonu. Pre nás bol väčším rozdielom ekosystém. Vite už tvoril spoločný základ väčšiny nášho frontendového kódu, mal širší ekosystém pluginov a umožňoval väčšie opätovné využitie konfigurácie medzi projektmi.
Ponechanie Next.js na Cloudflare by teda vyriešilo časť problému s hostingom, no zachovalo by nesúlad medzi frameworkmi aj samostatný ekosystém nástrojov na zostavovanie aplikácií.
Preto sme ustúpili o krok späť a pozreli sa na to, čo jednotlivé časti systému skutočne potrebujú.
Stack sme rozdelili podľa potrieb jednotlivých častí systému
Keď sme prestali hľadať jednu univerzálnu náhradu za Next.js, architektúra sa výrazne zjednodušila.
Naše marketingové stránky potrebovali SSR, pretože majú verejné lokalizované stránky, metadáta, kanonické URL adresy, mapy stránok a návštevnosť z vyhľadávačov.
Väčšina našich ostatných webových aplikácií SSR nepotrebovala a mohla byť jednoducho aplikáciami Vite s TanStack Routerom.
Naše API nepotrebovali framework React vôbec a lepšie im vyhovovalo bežné runtime prostredie Node.js.
Výsledné rozdelenie vyzeralo takto:
Webové aplikácie
Vite + TanStack Router
│
└── Cloudflare Workers
Marketingové stránky
TanStack Start + SSR
│
└── Cloudflare Workers
API
Hono + tRPC
│
└── Railway / kontajnery Node.js
Pravidlo bolo jednoduché: používajte SSR tam, kde prináša skutočnú hodnotu, obyčajnú SPA tam, kde SSR hodnotu neprináša, a backendové služby spúšťajte v prostredí určenom pre backend.
Z väčšiny webových aplikácií sa stali SPA
Migrácie na SPA boli najjednoduchšou časťou.
Webová aplikácia WebCatalogu sa presunula mimoriadne rýchlo: pripravili sme základ náhrady na Vite + TanStack Router, preniesli rozhranie, prepli nasadzovanie na Cloudflare Workers a ešte v to isté dopoludnie odstránili starú verziu v Next.js.
Rovnaký postup sme zopakovali pri webovej aplikácii Lexibird, nastaveniach účtu, vývojárskej konzole, autentifikácii a administračných aplikáciách. Od prípravy základu prvej SPA po odstránenie poslednej aplikácie Next.js uplynulo približne 19 dní.
Pri týchto aplikáciách je fungovanie Cloudflare Workers zámerne jednoduché. Vite zostaví statické súbory, Cloudflare ich poskytuje a požiadavky na aplikačné cesty sa v prípade potreby presmerujú na index.html. Neexistuje tu SSR runtime, pretože nič nepotrebuje renderovanie na serveri.
Ťažšie bolo zachovať správanie, ktoré sa okolo týchto aplikácií časom vytvorilo. Časť autentifikačnej logiky sa musela presunúť zo serverových ciest Next.js do API a staršie verzie desktopovej aplikácie WebCatalog stále záviseli od pôvodných endpointov, ktoré sme museli zachovať funkčné.
Presunúť používateľské rozhranie v Reacte bolo jednoduché.
Zachovať existujúce rozhrania a správanie bolo ťažšie.
Vyskúšali sme Astro a o päť dní ho odstránili
Marketingové stránky boli náročnejšie.
Našou prvou voľbou bolo Astro, ktoré sa zdalo byť prirodzenou voľbou pre webcatalog.io a lexibird.com, pretože obe sú verejné weby s množstvom obsahu a Astro sa dobre integruje s Cloudflare.
Začali sme prenášať obe stránky a o päť dní sme prestali.
Nešlo o jednu zásadnú chybu. Namiesto toho sa hromadili drobné nesúlady. Niektoré cesty potrebovali prístup k databáze pri predbežnom renderovaní, no naše prostredie na zostavovanie zámerne nemalo prístupové údaje k produkčnej databáze. React islands sťažovali prirodzené zdieľanie stavu aplikácie. Narazili sme aj na rozdiely medzi vopred renderovanými cestami a cestami renderovanými za behu a na určité komplikácie s nástrojmi v našom repozitári.
Žiaden z týchto problémov nebol neriešiteľný. Práve preto bolo nebezpečné pokračovať. Ľahko sme mohli stráviť ďalších niekoľko týždňov postupným opravovaním jedného problému za druhým.
Namiesto toho sme implementáciu odstránili a začali odznova.
AI agenti zmenili ekonomiku tohto rozhodnutia. Veľká časť mechanického prenosu nás nestála týždne práce inžinierov, takže náklady, ktoré už nebolo možné získať späť, boli menšie. Bolo preto jednoduchšie priznať si, že uprednostňujeme inú architektúru.
TanStack Start nám vyhovoval viac
Migráciu marketingových stránok sme začali odznova z pôvodného kódu Next.js, tentoraz s použitím TanStack Start.
Zapadol oveľa prirodzenejšie, pretože v SPA aplikáciách sme už používali TanStack Router. Smerovanie, loadery, parametre vyhľadávania a navigácia tak vychádzali z podobných konceptov. Kód zostal bežným Reactom a TypeScriptom a na zostavovanie sme používali Vite.
lexibird.com sme na TanStack Start preniesli za jeden deň. Potom nasledoval webcatalog.io.
Výhodou nebolo to, že by TanStack Start zázračne vyriešil každý problém. Výhodou bolo, že zodpovedal smeru, ktorým sa už uberal zvyšok nášho stacku.
V monorepozitári na tom záleží. Spoločné nástroje na zostavovanie znamenajú viac opätovne využiteľných pluginov a konfigurácií, menej výnimiek pri ladení, menej prepínania kontextu pre vývojárov a menej konvencií špecifických pre jednotlivé projekty, ktoré musia agenti na programovanie objavovať.
Cloudflare bol pri našej návštevnosti oveľa lacnejší
Architektúra bola iba jedným z dôvodov, prečo naše náklady klesli. Dôležitým faktorom boli ceny Cloudflare, najmä prenos dát.
Platený program Cloudflare Workers v súčasnosti účtuje predovšetkým požiadavky a využitie CPU a pri Workers neúčtuje dodatočné poplatky za prenos dát ani šírku pásma. (developers.cloudflare.com) Pri verejných weboch to má veľký význam, pretože požiadavka môže spotrebovať veľmi málo výkonu CPU, no napriek tomu preniesť HTML, JavaScript, obrázky, fonty a ďalšie súbory.
Cenový model Vercelu zahŕňa aj kategórie a limity týkajúce sa sieťovej prevádzky vrátane Fast Data Transfer a Fast Origin Transfer. (vercel.com) Pri našom profile návštevnosti bola ekonomika Cloudflare výrazne výhodnejšia.
Úspory nevznikli len zmenou poskytovateľa. Mnohé aplikácie sme presunuli na statické zostavenia pomocou Vite, obmedzili zbytočné SSR, nastavili ukladanie do vyrovnávacej pamäte explicitnejšie a API presunuli do prostredia, ktoré im lepšie vyhovovalo. Ceny Cloudflare, najmä pri prenose dát, však významne prispeli k približne 80 % zníženiu, ktoré sme zaznamenali.
Toto číslo platí pre naše konkrétne využitie. Netvrdíme, že každá aplikácia pri presune z Vercelu na Cloudflare ušetrí 80 %.
API napokon skončili na Railway
API predstavovali samostatný problém.
Hoci išlo o projekty Next.js, už predtým boli od Next.js z veľkej časti nezávislé. API WebCatalogu malo približne 34 000 riadkov, ale next/server importovalo iba sedem súborov. tRPC už používalo svoj adaptér Fetch a Inngest podporoval Hono.
HTTP vrstvu Next.js sme nahradili frameworkom Hono. Táto časť bola prekvapivo malá.
Ťažšou otázkou bolo, kde API prevádzkovať. Samotné Workers neboli vhodné, pretože API používajú Node.js a natívne závislosti, napríklad sharp.
Najprv sme vyskúšali Cloudflare Containers, vďaka ktorým sme sa rýchlo odpútali od Vercelu. Po nasadení do produkcie sme však zistili, že tento prevádzkový model vyžaduje viac manuálneho nastavovania kapacity, než sme vtedy chceli.
Preto sme API presunuli znova.
Dnes bežia na Railway ako bežné dlho bežiace kontajnerové služby Node.js. CI (priebežná integrácia) zostavuje obrazy Dockeru a odosiela ich do nášho registra, zatiaľ čo Railway zabezpečuje horizontálne automatické škálovanie.
Nie všetko musí bežať na okraji siete.
Odchod z Vercelu znamenal prevziať viac zodpovednosti
Nižšie náklady mali aj svoju cenu.
Vercel a Next.js sa starali o mnohé aspekty infraštruktúry na vyššej úrovni. Pri TanStack Start a Workers sme sa namiesto toho posunuli k explicitnému HTTP cachovaniu. Stránka sa vyrenderuje, vrátime hlavičky určujúce ukladanie do vyrovnávacej pamäte a Cloudflare uloží odpoveď. Ukladanie do vyrovnávacej pamäte v prehliadači a na okraji siete môže mať odlišné pravidlá vrátane správania stale-while-revalidate na okraji siete.
Páčilo sa nám, že tieto rozhodnutia sú explicitné, ale explicitná infraštruktúra tiež znamená, že za chyby zodpovedáte vy.
Niekoľko sme ich urobili. Jedno produkčné pravidlo vyrovnávacej pamäte omylom zachytilo odpovede serverových funkcií TanStack určené konkrétnym návštevníkom a iná konfigurácia vyrovnávacej pamäte sa nešťastne ovplyvňovala so správaním záložného smerovania SPA. Tieto chyby nám pripomenuli, že správnosť migrácie nemožno dokázať len na základe repozitára. Súčasťou systému je aj produkčná infraštruktúra.
AI agenti zmenili spôsob, akým sme migrovali
Väčšinu implementačnej práce vykonali agenti na programovanie, predovšetkým Claude Fable 5 a Claude Opus 5.
Migrácie frameworkov sa pre agentov mimoriadne hodia, pretože veľká časť práce má jasný existujúci vzor. Preniesť túto cestu, zachovať túto URL adresu, nahradiť toto API frameworku, ponechať rovnaké metadáta, spustiť kontrolu typov, opraviť chyby a porovnať výsledok so starou implementáciou.
Pre webcatalog.io sme viedli prehľad migrácie, ktorý prácu rozdeľoval na etapy, ako boli základy, produktové stránky, katalógové stránky, vyhľadávanie, blog, cenník, presmerovania, mapy stránok a prepnutie na nové riešenie. Namiesto požiadavky, aby agent „migroval webcatalog.io na TanStack Start“, sme mu zadávali ohraničené úlohy s explicitne určenými pravidlami, ktoré sa nesmeli zmeniť.
Existujúca aplikácia sa stala špecifikáciou. Úlohou agenta bolo reprodukovať jej správanie pomocou novej architektúry, nie nanovo vymýšľať produkt.
Ľudská práca sa tak presunula od manuálneho prepisovania kódu k otázkam, ako napríklad: Naozaj má táto stránka používať SSR? Ktoré správanie je zámerné? Čo sa môže globálne ukladať do vyrovnávacej pamäte? Ktoré URL adresy musia zostať identické? Kde má prebiehať autentifikácia? Kedy máme prestať skúšať, či určité riešenie dokážeme uviesť do prevádzky?
Výstupy sme stále kontrolovali, spúšťali zostavenia a kontroly typov a manuálne overovali rizikovejšie oblasti, ako sú autentifikácia, SEO (optimalizácia pre vyhľadávače), presmerovania a ukladanie do vyrovnávacej pamäte.
Dôležitou zmenou nebolo to, že za nás AI písala kód. Bolo ňou to, že AI zlacnila experimentovanie.
Vyskúšať Astro a po piatich dňoch ho odstrániť sa dalo oveľa ľahšie obhájiť. Presunúť API na jednu platformu a potom sa rozhodnúť, že vhodnejšia je iná, bolo menej bolestivé. Mechanická práca bola lacnejšia, takže keď bola architektúra nesprávna, mohli sme zmeniť smer namiesto toho, aby sme pokračovali len preto, že sme do nej už priveľa investovali.
Vďaka agentom prestala byť implementačná kapacita taká vzácna.
O to dôležitejšími sa stali architektúra, obmedzenia, kontrola a overovanie.
Z 80 % sa stalo približne 90 %
Po migrácii boli naše náklady na webovú infraštruktúru približne o 80 % nižšie.
Potom sme začali venovať väčšiu pozornosť tomu, ktoré požiadavky sa k aplikáciám vôbec dostanú.
Významnú časť verejnej internetovej návštevnosti tvorí automatizovaná prevádzka: vyhľadávače, AI crawlery, agenti, nástroje na získavanie dát z webu, skenery a menej priateľské boty. Časť tejto návštevnosti je užitočná, časť nie.
Keďže aplikácie boli priamo za Cloudflare, sprísnili sme bezpečnostné pravidlá tak, aby sa škodlivá automatizovaná návštevnosť dala odmietnuť na okraji siete skôr, než vyvolá výpočty v aplikácii alebo prácu s databázou.
Celková úspora potom oproti pôvodnému riešeniu dosiahla približne 90 %.
Na výslednom znížení nákladov sa podieľalo viacero vecí spoločne: nižšie ceny Cloudflare, najmä za prenos dát; menej práce na strane servera; vhodnejšie runtime prostredie pre naše API; explicitnejšie ukladanie do vyrovnávacej pamäte; a menej zbytočných požiadaviek, ktoré sa vôbec dostali k aplikáciám.
Kde sme skončili
V našom repozitári už nezostali žiadne aplikácie Next.js. Väčšina našich webových aplikácií sú teraz SPA využívajúce Vite + TanStack Router na Cloudflare Workers. webcatalog.io a lexibird.com používajú TanStack Start na Cloudflare Workers, pretože týmto stránkam SSR skutočne prospieva. Naše API používajú Hono + tRPC na Railway a bežia ako bežné kontajnery Node.js. Takmer všetky naše frontendové projekty teraz patria do ekosystému Vite.
Náklady na infraštruktúru nám klesli približne o 80 %, k čomu výrazne prispeli podstatne výhodnejšie ceny Cloudflare pre našu návštevnosť, najmä pri prenose dát. Filtrovanie škodlivej automatizovanej návštevnosti na okraji siete zvýšilo celkovú úsporu približne na 90 %.
Najviac nám však záleží na výslednej architektúre. Marketingové stránky majú SSR, všetko ostatné, čo môže byť SPA, je SPA, a API bežia na skutočných serveroch, keď je to jednoduchšie.
Začali sme snahou zlacniť Vercel.
Skončili sme pri zistení, že väčšinu architektúry, za ktorú sme platili, sme vôbec nepotrebovali.