- Tim Hardcover bermigrasi ke Ruby on Rails + Inertia.js karena penurunan performa arsitektur berbasis Next.js, biaya tinggi, dan melambatnya kecepatan pengembangan
- Memilih Inertia.js untuk memenuhi kebutuhan dukungan SSR yang ramah SEO, koneksi langsung ke DB, dan tetap mempertahankan React
- Lonjakan biaya tak terduga di Vercel dan Cloud Run serta ketidakpastian caching di Next.js menjadi pemicu utama perpindahan ini
- Inertia.js menjadi cara ideal untuk menghubungkan backend Rails dan frontend React, sehingga SSR dan pengelolaan cache menjadi lebih mudah
- Setelah perpindahan, skor Google Pagespeed dan SEO meningkat, serta durasi kunjungan situs dan visibilitas pencarian ikut naik
Latar belakang perpindahan
- Pada awalnya mereka memilih Next.js yang mendukung SEO dan SSR, lalu membangun arsitektur berbasis GraphQL API
- Sebagian besar data diminta secara client-side dari browser, sementara data statis di-cache di server
- Seiring waktu, terjadi peningkatan permintaan API akibat tidak adanya caching, penurunan performa, dan melambatnya kecepatan lingkungan pengembangan
Masalah yang muncul di Next.js
- Setelah beralih ke App Router pun peningkatan kecepatan minim, dan request Apollo POST tidak di-cache sehingga efek yang diharapkan tidak tercapai
- Perubahan kebijakan harga Vercel membuat biaya bulanan melonjak dari $30 → $354
- Cloud Run juga awalnya murah, tetapi kemudian naik hingga $524
- Sulit memahami struktur caching Next.js, sehingga tidak bisa dikelola secara efisien
- Kecepatan pengembangan menurun drastis dan menyulitkan onboarding anggota baru
Alasan memilih Rails + Inertia.js
- Ingin tetap mempertahankan SSR sambil mengambil data langsung dari DB
- Mereka ingin terus menggunakan React, dan sempat meninjau Remix, react-rails, react_on_rails, tetapi akhirnya memilih inertia-rails
- Inertia.js memungkinkan penggunaan routing Rails tanpa frontend routing, dan SSR juga lebih mudah
- Di controller, rendering ditangani dengan
inertia: 'nama halaman', sementara caching diimplementasikan dengan Rails.cache.fetch
- Props diterima di komponen React melalui
usePage()
Struktur SSR dan build
- Untuk SSR, di
application.tsx diterapkan pemisahan hydrateRoot / createRoot
- Vite dijalankan sebagai server terpisah dan mendukung hot reload saat pengembangan
- Otomatisasi deployment Rails + Vite dilakukan dengan Docker dan Kamal, serta memisahkan staging dan production
- Saat deployment, dijalankan dengan perintah
make deploy, dan asset host menggunakan CloudFlare untuk mengoptimalkan cache
Dampak setelah perpindahan
- Setelah deployment migrasi pada 18 Maret 2025, visibilitas di Google Search meningkat dan kecepatan halaman membaik
- Total Blocking Time membaik secara signifikan, disertai kenaikan skor Pagespeed
- Rata-rata durasi kunjungan pengunjung menunjukkan tren naik dari 3 menit → 6 menit
- Trafik tetap terjaga, sementara jumlah pendaftaran anggota juga stabil
Tantangan dan perbaikan ke depan
- Ada kendala pada sulitnya penggunaan ulang layout bersama dan masalah rerender penuh di setiap halaman
- Debugging SSR sulit, dan penyiapan lingkungan cukup kompleks
- Dokumentasi kombinasi Inertia.js dan Rails masih kurang, sehingga banyak solusi ditemukan lewat komunitas Discord
- Perlu beradaptasi dengan pendekatan Inertia sebagai pengganti Suspense
- Saat ini masih tetap menggunakan Hasura, sehingga beberapa fitur Inertia seperti form dan flash belum dimanfaatkan
Kesimpulan dan harapan
- Struktur yang mengintegrasikan React + Rails secara alami meningkatkan produktivitas pengembangan dan kemudahan pemeliharaan
- Dengan memilih Inertia.js, mereka berhasil mendapatkan kecepatan, SSR, dan type safety secara bersamaan
- Ke depan mereka berencana membuka source code dan menarik lebih banyak kontributor
2 komentar
Ada kontroversi karena saat menggunakan
Linkdi Next.js, URL dibuat dan diproses dalam bentuk seperti?_rsc=1ip3iuntuk memakai React Server Components. Ada juga kabar bahwa biaya penggunaan CDN melonjak drastis, dan disebutkan bahwa tim pengembang Next.js juga sudah menyadari masalah ini, tetapi belum jelas dengan cara apa dan kapan masalah tersebut akan diselesaikan.Komentar Hacker News
Server-side rendering (SSR) tidak pernah benar-benar hilang, dan web baru sekarang mengingat kembali alasan mengapa itu dulu menjadi default. Render pertama dan SEO masih lebih baik ketika markup datang dari server. Berbagai framework seperti Rails + Turbo, HTMX, Phoenix LiveView, dan React Server Components menjadikan SSR sebagai dasar. Sebagian besar dashboard dan aplikasi CRUD tidak membutuhkan client router, global state, atau bundle hidrasi 200kB, melainkan hanya penggantian HTML sebagian
Pendorong sebenarnya adalah biaya kompleksitas. Setiap baris JS di klien membawa alat build, kebisingan audit npm, dan risiko rantai pasok. Mengurangi payload ini meningkatkan performa dan keamanan sekaligus. Tentu saja, aplikasi seperti Figma atau Gmail masih mendapat manfaat dari logika klien yang berat. Karena itu, pola yang muncul adalah "HTML secara default, JS hanya di tempat yang diperlukan". Pikirkan island, bukan SPA penuh
Jadi memang ada pergeseran kembali ke server, tetapi ini bukan nostalgia ke PHP tahun 2004. Ini soal mengatur JavaScript dengan tepat dan membiarkan HTML mengerjakan 90% pekerjaan membosankan yang memang selalu dikuasainya
Kami menggunakan NextJS di beberapa proyek, tetapi sekarang sudah mulai menghentikannya secara bertahap. Alasannya bermacam-macam, tetapi beberapa faktor utama adalah sebagai berikut
Cerita autentikasinya sulit. next-auth punya beberapa keterbatasan sehingga kami akhirnya memakai iron-session. Misalnya, tidak bisa menggunakan domain penyedia ID dinamis, jadi kami harus memiliki seluruh alur openid sendiri. Itu memang bisa dilakukan, tetapi terasa seperti penguras waktu yang tidak terduga untuk framework yang seharusnya matang
Karena server NextJS bukan API gateway utama kami, kami harus mem-proxy semua request. Dokumentasinya tidak jelas, dan ini menambah masalah acak seperti request timeout/maksimum ukuran header dan sebagainya
Framework ini sangat agresif mendorong perpindahan ke cloud, dan itu bertentangan dengan tujuan kami
Para maintainer-nya juga tidak terlalu membantu. Alat/framework lain tetap kami pakai meskipun ada kekurangan karena maintainer-nya sangat mudah dihubungi dan membantu (terima kasih untuk Chillicream/HotChocolate)
Saya ingat pernah membaca posting blog tahun lalu yang menyatakan SEO membaik saat berpindah dari page router ke app router di Next.js. Kali ini kami pindah dari Next ke React+Inertia.js karena kenaikan biaya Vercel. Mendeploy aplikasi yang sama ke VPS sendiri alih-alih ke penyedia cloud semestinya akan menyelesaikan masalah. Namun saya tidak paham mengapa orang menginginkan kompleksitas ini. Apakah aplikasi pelacak buku benar-benar membutuhkan GraphQL, framework frontend terpisah, dan proses build yang rumit, atau sebenarnya semua itu bisa diselesaikan dengan mendeploy satu aplikasi RoR dengan template HTML ke VPS sejak awal
Setiap kali melihat artikel dan diskusi tentang web dan stack, saya jadi bertanya, "masalah apa sebenarnya yang sedang diselesaikan?" Jawabannya selalu "menampilkan teks di layar"
Saya penasaran apa yang dilakukan orang saat mereka ingin JS full stack, terutama jika melibatkan DB. Situasi ORM cukup terpecah-pecah, atau kita harus menulis SQL murni. Dan backend tetap harus diputuskan. Pakai express? Next.js terkenal, tetapi terasa punya agenda yang meragukan. Remix, Astro, TanStack, dan lainnya. Semuanya terasa membingungkan karena kita selalu harus menyesuaikan dan mengevaluasi ulang apa yang harus dipakai
Untuk proyek pribadi, saya sering kembali ke Ruby on Rails. Selalu menyenangkan. Di sisi lain, jumlah developer Rails yang tersedia terlalu sedikit (dibandingkan dengan JS), jadi kurang cocok untuk proyek profesional. Memilih JS dan sering kali Java untuk backend rasanya bukan tindakan yang tidak bertanggung jawab
Saya penasaran apakah ada orang lain yang merasakan hal serupa
Developer frontend dan backend sudah lama tidak terlalu nyambung satu sama lain
Secara historis, sebagai developer backend saya membenci Html/JS/CSS. Itu paradigma yang sangat berbeda dibanding Swing/Awt, WinForms, Android UX, dan sebagainya. Itu saja sudah cukup membuat saya frustrasi dan tetap bertahan di backend. Untuk mempelajari frontend, saya harus mempelajari ketiganya. Baru sekarang saya mulai terbiasa
Namun developer frontend harus mempelajari "bahasa lain lagi". Banyak bahasa punya sistem build yang berbeda/menjengkelkan dibanding nvm. Dan siapa pun yang pernah pindah bahasa tahu bahwa kita juga harus mempelajari framework, paradigma, dan sebagainya yang baru
Sebagai gantinya, sebagian orang menyadari bahwa JavaScript bisa didorong ke backend. Ada banyak kekurangan, tetapi bagi orang-orang yang "harus menyelesaikan pekerjaan", terutama di dunia "tambah saja lebih banyak server" dan "pendanaan VC itu gratis! bakar saja untuk infrastruktur!", kekurangan itu bukan sesuatu yang terlalu dikhawatirkan
Namun para developer frontend, yang sekarang menjadi "full stack developer" tetapi sebenarnya lebih seperti developer "semuanya dengan JavaScript", terus berkarya dengan cara yang mencolok. Ini tercermin dalam lowongan kerja LinkedIn saat ini, yang meminta peran Next.JS/Node.JS/dan lainnya. Satu bahasa untuk menguasai semuanya
Hanya beberapa pemikiran, tetapi saya rasa ini sangat terkait dengan alasan orang memilih Next.JS
Saya tidak bisa banyak bicara soal sisi teknisnya (karena saya hanya akrab dengan Next.js dan tidak akrab dengan Rails, jadi tidak jelas apakah tulisan ini mencerminkan kenyamanan penulis dengan Rails atau arsitektur yang secara teknis lebih cocok). Namun menurut saya aneh jika perusahaan dengan beberapa software engineer mengkhawatirkan biaya infrastruktur kurang dari $1.000 per bulan. Mengkhawatirkan biaya hosting terasa kurang bijak
Jika Rails benar-benar fokus pada dukungan kelas satu untuk interoperabilitas dengan framework frontend yang dibawanya, sekarang mungkin sudah jauh lebih besar. Mereka mencurahkan banyak upaya ke Hotwire, tetapi saya ingin menggunakan React, dan orang lain juga mungkin ingin memakai hal yang sudah mereka kenal
Saya bertanya-tanya mengapa ada perdebatan Next.js vs. SSR. Next.js itu hibrida dan bekerja cukup baik. Berbeda dengan framework SPA lain, Next.js menghasilkan output HTML yang sudah dirender lebih dulu untuk first load yang cepat, menyediakan sakelar konfigurasi seperti JS chunk yang efisien, preloading saat hover pada link atau untuk semua link n+1 setelah halaman dirender, serta pemuatan gambar yang efisien (pra-muat) sesuai breakpoint (yang biasanya menjadi titik lemah jika dibandingkan dengan solusi SSR murni)
Saya pernah menulis sedikit Rails, tetapi saya kurang paham mengapa orang begitu antusias. Pengalamannya sepenuhnya baik-baik saja, tetapi saya tidak menemukan sesuatu yang istimewa