Selama bertahun-tahun, Vercel ialah platform utama yang kami gunakan untuk melancarkan hampir semua perkara berkaitan web di WebCatalog. Kebanyakan projek itu menggunakan Next.js, jadi gabungan tersebut terasa semula jadi. Laman pemasaran, antara muka produk, tetapan akaun, konsol pembangun, pengesahan, alat pentadbiran dan API kami semuanya menggunakan timbunan teknologi yang lebih kurang sama.
Pendekatan itu berfungsi dengan baik untuk tempoh yang lama. Vercel memudahkan pelancaran, Next.js menyediakan rangka kerja tindanan penuh yang produktif, dan kami jarang perlu memikirkan infrastruktur di sebalik kedua-duanya.
Akhirnya, kemudahan itu tidak lagi sepadan dengan keperluan produk kami.
Laman pemasaran kami masih mendapat manfaat daripada SSR (pemaparan sebelah pelayan), tetapi kebanyakan aplikasi web kami yang lain tidak. Aplikasi tersebut boleh menjadi SPA (aplikasi satu halaman) biasa. API kami memerlukan persekitaran Node.js biasa dengan kebergantungan natif dan proses yang berjalan lama. Hampir semua komponen lain dalam timbunan frontend kami sudah menggunakan Vite. Pada masa yang sama, kos infrastruktur semakin sukar diabaikan, khususnya apabila trafik awam dan trafik automatik meningkat.
Pada mulanya, kami cuba mengoptimumkan apa yang sudah kami miliki. Kami mempertimbangkan untuk mengekalkan Next.js dan memindahkannya ke Cloudflare Workers melalui penyesuai. Kami mencuba Astro untuk laman pemasaran. Kami juga menggunakan Cloudflare Containers untuk API kami buat seketika.
Akhirnya, kami memilih susunan yang lebih ringkas: kebanyakan aplikasi web kami kini menggunakan Vite + TanStack Router pada Cloudflare Workers, laman pemasaran kami menggunakan TanStack Start dengan SSR pada Cloudflare Workers, dan API kami menggunakan Hono + tRPC pada Railway sebagai kontena Node.js yang berjalan lama.
Migrasi itu mengurangkan kos infrastruktur web kami sebanyak kira-kira 80%. Selepas kami turut memperketat peraturan keselamatan Cloudflare dan menyekat lebih banyak trafik automatik yang berniat jahat di pinggir rangkaian, jumlah penjimatan meningkat kepada sekitar 90%.
Sebahagian besar pelaksanaan migrasi juga dilakukan oleh ejen pengekodan AI, terutamanya Claude Fable 5 dan Claude Opus 5, sementara jurutera menentukan seni bina, menetapkan kekangan, menyemak perubahan dan mengesahkan hasilnya.
Kami Tidak Bermula dengan Meninggalkan Vercel
Naluri pertama kami ialah mengoptimumkan sistem sedia ada.
webcatalog.io ialah tempat paling jelas untuk bermula kerana laman itu menerima banyak trafik awam, sedangkan kebanyakan halamannya jarang berubah. Kami mendapati terlalu banyak bahagian laman masih dipaparkan secara dinamik. Jadi, kami membetulkan pemaparan dinamik yang tidak disengajakan, menambahkan ISR (Penjanaan Semula Statik Berperingkat) pada laluan bertrafik tinggi, menjadikan lebih banyak halaman boleh dicache, dan mengoptimumkan proses peta laman yang menggunakan banyak sumber.
Usaha itu membantu, tetapi juga menjadikan masalah asas lebih jelas. Kami semakin banyak meluangkan masa untuk memahami mengapa kandungan yang agak statik dipaparkan secara dinamik, tingkah laku rangka kerja mana yang menyebabkannya, dan ciri rangka kerja mana yang perlu kami gunakan supaya kandungan itu boleh dicache semula.
Sementara itu, banyak aplikasi kami yang lain menghadapi masalah sebaliknya. Tetapan akaun, konsol pembangun, aplikasi pentadbiran dan kebanyakan antara muka produk langsung tidak memerlukan pemaparan sebelah pelayan. Semuanya ialah aplikasi pelayar yang berkomunikasi dengan API.
Pada ketika itu, persoalannya bukan lagi “Bagaimana kita boleh mengurangkan bil Vercel?” tetapi “Apa yang akan kita bina jika aplikasi ini bukan aplikasi Next.js sejak awal?”
Kami Mempertimbangkan Next.js pada Cloudflare
Pilihan yang paling kurang mengganggu ialah mengekalkan Next.js dan memindahkannya daripada Vercel ke Cloudflare Workers.
Kami mempertimbangkan pilihan ini dengan serius kerana Next.js boleh berjalan pada Cloudflare melalui lapisan penyesuai, yang membolehkan kami mengekalkan sebahagian besar struktur aplikasi sedia ada.
Namun, kami tidak menganggap Next.js pada Cloudflare setara dengan Next.js pada Vercel. Next.js paling rapat bersepadu dengan masa jalan, sistem pelancaran, tingkah laku cache dan ciri platform Vercel. Pada Cloudflare, penyesuai perlu menterjemahkan andaian tersebut kepada masa jalan yang berbeza.
Itu boleh berfungsi dengan baik, tetapi jika matlamat kami ialah memudahkan timbunan teknologi, menambah satu lagi lapisan keserasian terasa kurang sesuai.
Ada juga isu perkakasan pembangunan yang lebih luas. Hampir semua perkara lain yang kami bina pada bahagian frontend sudah menggunakan Vite: aplikasi desktop, sambungan pelayar, SPA dan projek sebelah klien yang lain.
Next.js telah banyak beralih ke arah Turbopack, dan Turbopack telah bertambah baik dengan ketara. Ini bukan rungutan tentang prestasi. Bagi kami, perbezaan yang lebih besar ialah ekosistemnya. Vite sudah menjadi asas bersama bagi kebanyakan kod frontend kami, dengan ekosistem pemalam yang lebih luas serta konfigurasi yang lebih mudah digunakan semula merentas projek.
Oleh itu, mengekalkan Next.js pada Cloudflare akan menyelesaikan sebahagian masalah pengehosan, tetapi masih mengekalkan ketidakpadanan rangka kerja dan ekosistem alat binaan yang berasingan.
Jadi, kami mengambil langkah ke belakang dan menilai keperluan sebenar setiap beban kerja.
Kami Membahagikan Timbunan Teknologi Mengikut Beban Kerja
Sebaik sahaja kami berhenti mencari satu pengganti Next.js yang sesuai untuk semua kegunaan, seni binanya menjadi lebih ringkas.
Laman pemasaran kami memerlukan SSR kerana laman tersebut mempunyai halaman awam dalam pelbagai bahasa, metadata, URL kanonik, peta laman dan trafik enjin carian.
Kebanyakan aplikasi web kami yang lain tidak memerlukan SSR dan boleh menjadi aplikasi Vite yang menggunakan TanStack Router.
API kami langsung tidak memerlukan rangka kerja React dan lebih sesuai dijalankan dalam masa jalan Node.js biasa.
Pembahagian akhirnya kelihatan seperti ini:
Aplikasi web
Vite + TanStack Router
│
└── Cloudflare Workers
Laman pemasaran
TanStack Start + SSR
│
└── Cloudflare Workers
API
Hono + tRPC
│
└── Railway / kontena Node.js
Prinsipnya menjadi mudah: gunakan SSR apabila ia memberikan nilai sebenar, gunakan SPA biasa apabila SSR tidak diperlukan, dan jalankan perkhidmatan backend dalam masa jalan backend.
Kebanyakan Aplikasi Web Menjadi SPA
Migrasi SPA ialah bahagian yang paling mudah.
Aplikasi web WebCatalog dipindahkan dengan sangat cepat: kami menyediakan asas pengganti menggunakan Vite + TanStack Router, memindahkan antara mukanya, menukar pelancaran ke Cloudflare Workers dan menghapuskan versi Next.js lama pada pagi yang sama.
Kami mengulangi corak yang sama untuk aplikasi web Lexibird, tetapan akaun, konsol pembangun, pengesahan dan aplikasi pentadbiran. Dari penyediaan asas SPA pertama hingga penghapusan aplikasi Next.js terakhir, proses itu mengambil masa kira-kira 19 hari.
Bagi aplikasi ini, penggunaan Cloudflare Workers sengaja dibuat seringkas mungkin. Vite membina aset statik, Cloudflare menyediakannya, dan laluan aplikasi kembali ke index.html apabila perlu. Tiada masa jalan SSR kerana tiada apa-apa yang memerlukan pemaparan sebelah pelayan.
Bahagian yang lebih sukar ialah mengekalkan tingkah laku yang telah terbina di sekitar aplikasi tersebut dari semasa ke semasa. Sebahagian logik pengesahan perlu dipindahkan daripada laluan pelayan Next.js ke API, dan versi lama aplikasi desktop WebCatalog masih bergantung pada titik akhir lama yang perlu kami pastikan terus berfungsi.
Memindahkan UI React itu mudah.
Mengekalkan kontrak sedia ada lebih sukar.
Kami Mencuba Astro dan Menghapuskannya Lima Hari Kemudian
Laman pemasaran lebih mencabar.
Pilihan pertama kami ialah Astro, yang kelihatan sesuai untuk webcatalog.io dan lexibird.com kerana kedua-duanya ialah laman awam yang kaya dengan kandungan, dan Astro berintegrasi dengan baik dengan Cloudflare.
Kami mula memindahkan kedua-dua laman tersebut, tetapi berhenti lima hari kemudian.
Tiada satu kelemahan besar yang menyebabkan keputusan itu. Sebaliknya, ketidakpadanan kecil terus bertambah. Sesetengah laluan memerlukan akses pangkalan data semasa prapemaparan, sedangkan persekitaran binaan kami sengaja tidak mempunyai kelayakan pangkalan data produksi. Penggunaan pulau React menjadikan perkongsian keadaan aplikasi kurang semula jadi. Kami juga menemui perbezaan antara laluan yang diprapaparkan dengan laluan yang dipaparkan semasa masa jalan, serta beberapa masalah dengan alat pembangunan dalam repositori kami.
Semua masalah itu boleh diselesaikan. Itulah sebabnya meneruskannya berisiko. Kami boleh sahaja menghabiskan beberapa minggu lagi untuk membetulkan satu demi satu masalah.
Sebaliknya, kami menghapuskan pelaksanaan itu dan bermula semula.
Ejen AI mengubah pertimbangan kos keputusan tersebut. Sebahagian besar kerja pemindahan yang mekanikal tidak mengambil masa jurutera berminggu-minggu, jadi kos masa dan usaha yang sudah dilaburkan lebih kecil. Ini memudahkan kami mengakui bahawa kami lebih menyukai seni bina lain.
TanStack Start Lebih Sesuai
Kami memulakan semula migrasi laman pemasaran daripada kod Next.js asal, kali ini menggunakan TanStack Start.
Ia terasa jauh lebih sesuai kerana kami sudah menggunakan TanStack Router dalam aplikasi SPA. Oleh itu, penghalaan, pemuat data, parameter carian dan navigasi mengikuti konsep yang serupa. Kodnya kekal sebagai React dan TypeScript biasa, manakala sistem binaannya ialah Vite.
Kami memindahkan lexibird.com ke TanStack Start dalam masa sehari. webcatalog.io menyusul selepas itu.
Kelebihannya bukanlah TanStack Start menyelesaikan setiap masalah secara ajaib. Kelebihannya ialah ia sepadan dengan hala tuju timbunan teknologi kami yang lain.
Dalam monorepo, perkara itu penting. Perkongsian alat binaan bermakna lebih banyak pemalam dan konfigurasi boleh digunakan semula, lebih sedikit kes khas ketika menyahpepijat, kurang pertukaran konteks bagi pembangun, dan lebih sedikit konvensyen khusus projek yang perlu dikenal pasti oleh ejen pengekodan.
Cloudflare Jauh Lebih Murah untuk Corak Trafik Kami
Seni bina hanyalah sebahagian daripada sebab bil kami menurun. Harga Cloudflare merupakan faktor utama, terutamanya bagi lebar jalur.
Pelan berbayar Cloudflare Workers pada masa ini mengenakan caj terutamanya berdasarkan bilangan permintaan dan penggunaan CPU, serta tidak mengenakan caj pemindahan data atau lebar jalur tambahan untuk Workers. (developers.cloudflare.com) Ini amat penting bagi laman web awam kerana sesuatu permintaan mungkin menggunakan sangat sedikit CPU tetapi masih memindahkan HTML, JavaScript, imej, fon dan aset lain.
Model harga Vercel turut merangkumi kategori penggunaan dan kuota berkaitan rangkaian, termasuk Fast Data Transfer dan Fast Origin Transfer. (vercel.com) Bagi corak trafik kami, kos Cloudflare jauh lebih rendah.
Penjimatan itu bukan semata-mata hasil pertukaran penyedia. Kami juga memindahkan banyak aplikasi kepada binaan Vite statik, mengurangkan SSR yang tidak perlu, menjadikan caching lebih jelas dan memindahkan beban kerja API ke masa jalan yang lebih sesuai. Namun, harga Cloudflare, khususnya bagi lebar jalur, ialah penyumbang utama kepada pengurangan kira-kira 80% yang kami lihat.
Angka itu khusus untuk beban kerja kami. Ia bukan dakwaan bahawa setiap aplikasi yang berpindah daripada Vercel ke Cloudflare akan menjimatkan 80%.
API Kami Berakhir di Railway
API merupakan cabaran yang berasingan.
Walaupun dibina sebagai projek Next.js, API tersebut sebenarnya sudah hampir bebas daripada Next.js. API WebCatalog mengandungi kira-kira 34,000 baris kod, tetapi hanya tujuh fail mengimport next/server. tRPC sudah menggunakan penyesuai Fetch, dan Inngest menyokong Hono.
Kami menggantikan lapisan HTTP Next.js dengan Hono. Bahagian itu ternyata tidak banyak kerja.
Persoalan yang lebih sukar ialah tempat untuk menjalankannya. Workers biasa tidak sesuai kerana API tersebut menggunakan Node.js dan kebergantungan natif seperti sharp.
Pada mulanya, kami mencuba Cloudflare Containers, yang membolehkan kami meninggalkan Vercel dengan cepat. Namun, selepas menjalankan susunan itu dalam produksi, kami mendapati model operasinya memerlukan lebih banyak pelarasan kapasiti secara manual daripada yang kami inginkan ketika itu.
Jadi, kami memindahkan API sekali lagi.
Kini API tersebut berjalan pada Railway sebagai perkhidmatan kontena Node.js biasa yang berjalan berterusan. CI (integrasi berterusan) membina imej Docker dan menghantarnya ke registri kami, manakala Railway mengurus penskalaan mendatar automatik.
Tidak semua perkara perlu berjalan di pinggir rangkaian.
Meninggalkan Vercel Bermakna Memikul Lebih Banyak Tanggungjawab
Kos yang lebih rendah datang dengan kompromi.
Vercel dan Next.js sebelum ini mengurus banyak aspek infrastruktur pada peringkat yang lebih tinggi. Dengan TanStack Start dan Workers, kami beralih kepada caching HTTP yang lebih jelas. Halaman dipaparkan, kami mengembalikan pengepala cache, dan Cloudflare menyimpan respons itu dalam cache. Cache pelayar dan cache di pinggir rangkaian boleh mempunyai dasar yang berbeza, termasuk tingkah laku stale-while-revalidate di pinggir rangkaian.
Kami suka apabila keputusan itu dibuat secara jelas, tetapi infrastruktur yang diurus secara jelas juga bermakna kesilapannya menjadi tanggungjawab kami.
Kami melakukan beberapa kesilapan. Satu peraturan cache produksi secara tidak sengaja turut terpakai pada respons fungsi pelayan TanStack yang khusus untuk pelawat tertentu, manakala satu lagi konfigurasi cache berinteraksi secara bermasalah dengan tingkah laku laluan sandaran SPA. Pepijat tersebut mengingatkan kami bahawa ketepatan migrasi tidak dapat dibuktikan sepenuhnya hanya melalui repositori. Infrastruktur produksi juga sebahagian daripada sistem.
Ejen AI Mengubah Cara Kami Melakukan Migrasi
Sebahagian besar kerja pelaksanaan dilakukan oleh ejen pengekodan, terutamanya Claude Fable 5 dan Claude Opus 5.
Migrasi rangka kerja amat sesuai untuk ejen kerana kebanyakan kerja mempunyai rujukan sedia ada yang jelas. Pindahkan laluan ini, kekalkan URL ini, gantikan API rangka kerja ini, kekalkan metadata yang sama, jalankan semakan jenis, betulkan ralat dan bandingkan hasilnya dengan pelaksanaan lama.
Untuk webcatalog.io, kami menyelenggara penjejak migrasi yang membahagikan kerja kepada peringkat seperti asas, halaman produk, halaman katalog, carian, blog, harga, ubah hala, peta laman dan peralihan akhir. Daripada meminta ejen “pindahkan webcatalog.io ke TanStack Start”, kami memberinya tugasan yang terbatas dengan syarat yang mesti dikekalkan secara jelas.
Aplikasi sedia ada menjadi spesifikasi. Tugas ejen ialah menghasilkan semula tingkah lakunya menggunakan seni bina baharu, bukan mereka bentuk semula produk.
Ini mengalihkan usaha manusia daripada menterjemah kod secara manual kepada persoalan seperti: Patutkah halaman ini menggunakan SSR? Tingkah laku yang mana disengajakan? Apa yang boleh dicache secara global? URL yang mana mesti kekal sama? Di manakah pengesahan patut berlaku? Bilakah kami patut berhenti mencuba untuk menjayakan sesuatu pendekatan?
Kami masih menyemak hasil kerja, menjalankan binaan dan semakan jenis, serta mengesahkan secara manual bahagian yang lebih berisiko seperti pengesahan, SEO (pengoptimuman enjin carian), ubah hala dan caching.
Perubahan yang penting bukanlah AI menulis kod untuk kami. Perubahan yang penting ialah AI menjadikan percubaan lebih murah.
Keputusan untuk mencuba Astro lalu menghapuskannya selepas lima hari menjadi lebih mudah untuk diterima. Memindahkan API sekali, kemudian memutuskan bahawa platform lain lebih sesuai, juga kurang membebankan. Kerja mekanikal menjadi lebih murah, jadi kami boleh menukar arah apabila seni binanya tidak tepat, bukannya meneruskan pendekatan lama hanya kerana kami sudah melabur terlalu banyak usaha padanya.
Ejen menjadikan kerja pelaksanaan lebih mudah diperoleh.
Ini menjadikan seni bina, kekangan, semakan dan pengesahan lebih penting.
80% Meningkat kepada Kira-kira 90%
Selepas migrasi, kos infrastruktur web kami kira-kira 80% lebih rendah.
Kemudian, kami mula memberi lebih perhatian kepada permintaan yang sampai ke aplikasi kami.
Sebahagian besar trafik internet awam dijana secara automatik: oleh enjin carian, perayap AI, ejen, pengikis data, pengimbas dan bot yang kurang mesra. Ada trafik sedemikian yang berguna dan ada yang tidak.
Dengan aplikasi berada terus di belakang Cloudflare, kami memperketat peraturan keselamatan supaya trafik automatik yang berniat jahat dapat ditolak di pinggir rangkaian sebelum mencetuskan pemprosesan aplikasi atau operasi pangkalan data.
Selepas itu, jumlah penjimatan kami mencapai kira-kira 90% berbanding dengan susunan lama.
Pengurangan akhir itu terhasil daripada beberapa faktor yang saling melengkapi: harga Cloudflare yang lebih rendah, khususnya bagi lebar jalur; kurang kerja sebelah pelayan; masa jalan yang lebih sesuai untuk API kami; caching yang lebih jelas; dan lebih sedikit permintaan yang tidak perlu sampai ke aplikasi.
Keadaan Kami Sekarang
Tiada lagi aplikasi Next.js dalam repositori kami. Kebanyakan aplikasi web kami kini ialah SPA Vite + TanStack Router pada Cloudflare Workers. webcatalog.io dan lexibird.com menggunakan TanStack Start pada Cloudflare Workers kerana kedua-dua laman itu benar-benar mendapat manfaat daripada SSR. API kami menggunakan Hono + tRPC pada Railway, berjalan sebagai kontena Node.js biasa. Hampir semua projek frontend kami kini berada dalam ekosistem Vite.
Kos infrastruktur kami turun kira-kira 80%, dengan kos Cloudflare yang jauh lebih rendah bagi corak trafik kami, khususnya lebar jalur, memberikan sumbangan besar. Penapisan trafik automatik yang berniat jahat di pinggir rangkaian meningkatkan penjimatan keseluruhan kepada sekitar 90%.
Namun, hasil yang paling penting bagi kami ialah seni binanya. Laman pemasaran mendapat SSR, semua aplikasi lain yang boleh menjadi SPA dijadikan SPA, dan API berjalan pada pelayan sebenar apabila penggunaan pelayan sebenar lebih mudah.
Kami bermula dengan usaha untuk mengurangkan kos Vercel.
Akhirnya, kami menyedari bahawa kami tidak memerlukan sebahagian besar seni bina yang selama ini kami bayar.