Rails untuk Segala-galanya - Kekuatan Rails untuk Semua

• Rails 8 sangat berguna untuk proyek berskala kecil dan pengembang perorangan
• Dengan panduan pemula terbaru, Anda dapat dengan mudah membangun aplikasi tingkat produksi
• Dengan peningkatan SQLite, Anda dapat menyiapkan lingkungan basis data yang kuat tanpa server tambahan
• Integrasi berkelanjutan (CI) bawaan dan generator autentikasi meningkatkan efisiensi pengembangan serta keamanan
• Deployment mudah dengan Kamal memungkinkan mengoperasikan layanan dengan cepat dan aman

---

Ikhtisar

• Berdasarkan pengalaman memanfaatkan Rails 8, ini adalah kerangka kerja web unggulan untuk proyek berskala kecil atau pengembang individual
• Melalui pembangunan cepat, deployment efisien, dan modul bawaan, keunggulan produktivitas dibanding framework pesaing menjadi menonjol

Kelebihan Panduan Terbaru

• Panduan Getting Started with Rails terbaru dirancang agar pemula juga bisa membuat aplikasi produksi
• Proses instalasi Ruby memang masih kompleks, tetapi cukup mengikuti panduan untuk bisa membangun layanan yang kokoh dengan fitur autentikasi, caching, rich text, CI, dan database yang semuanya sudah termasuk
• Kekuatan utamanya adalah bukan sekadar ‘Hello World’, melainkan menyediakan fondasi dan fitur pada level layanan nyata
• Menjadi titik awal yang ideal untuk pemula yang belum terbiasa dengan Rails

SQLite sudah cukup

• SQLite memang sudah hebat sebagai alat dasar, namun sebelumnya konfigurasinya untuk dipakai di produksi cukup sulit
• Dulu dibutuhkan pekerjaan tambahan seperti pemasangan gem tambahan, tetapi di Rails 8 Anda dapat memakainya di lingkungan produksi secara andal tanpa konfigurasi ekstra
• Anda tidak perlu menjalankan server PostgreSQL atau server terpisah lainnya, dan dengan solid cache Anda pun tidak membutuhkan server redis
• Layanan bisa berjalan hanya dengan Rails dan SQLite, memaksimalkan kesederhanaan serta efisiensi biaya saat pengembangan dan operasional

CI yang Mudah

• Sampai-sampai notifikasi kegagalan CI muncul setelah commit awal, karena Rails 8 menyediakan pengaturan CI terintegrasi secara bawaan
• Terkoneksi langsung dengan GitHub Actions tanpa konfigurasi tambahan, dan memberi Anda 2.000 menit waktu eksekusi gratis tiap bulan
• Bagi pengembang tunggal, ini termasuk waktu yang sangat mencukupi

Pengenalan Generator Autentikasi

• Gem autentikasi seperti Devise sebelumnya memang kuat, tetapi terasa rumit bagi pemula karena kompleksitas konfigurasi
• Rails 8 menambahkan generator autentikasi sederhana yang memungkinkan Anda menambahkan pengguna yang sudah ada lewat konsol untuk dengan mudah membuat alur login
• Kode yang dihasilkan sederhana dan mudah dibaca, sehingga mudah dipahami pemula

Deployment Cepat dan Mudah lewat Kamal

• Kamal menangani proses deployment sehingga cukup mengubah sebagian file deploy.yml dan mengikuti panduan, Anda bisa langsung menjalankan aplikasi dalam lingkungan SSL
• Ini memberi pengalaman deployment web app yang lebih cepat dibanding menghubungkan SSL ke GitHub Pages
• Kombinasi CI dan deployment yang mudah adalah salah satu aspek paling menonjol dari Rails 8
• Hanya dengan mengikuti panduan pemula, Anda dapat memperoleh pengalaman pengembangan yang selaras dengan praktik terbaik terbaru

Kesimpulan

• Rails tetap merupakan framework yang kuat dan terus berevolusi
• Jika Anda sedang mempertimbangkan proyek baru tahun ini, layak untuk mencoba pengembangan menggunakan Rails 8

[aer0700]

Akhir-akhir ini banyak banget tulisan soal SQLite, dan sekarang sampai semuanya jadi SQLite juga, ya.
Mungkinkah ini dianggap sebagai kebangkitan lagi era klasik?

[GN⁺]

Komentar Hacker News

• Akhir-akhir ini saya sedang membuat aplikasi dengan stack Spring Boot dan Micronaut, juga sampai ke frontend React. Pendekatan omakase Rails (semuanya sudah disertakan) terasa sangat terasa membantu. Fitur sederhana seperti validasi formulir dari backend atau pesan flash pun tidak langsung ditangani oleh framework, jadi saya harus mengimplementasikan sendiri atau mencari solusi pihak ketiga. Rails menyelesaikan masalah yang dihadapi sekitar 90% aplikasi web sejak awal. Mungkin tidak bisa dibilang sempurna, tapi di sebagian besar kasus fitur bawaan sudah cukup dan bisa diganti kapan saja kalau perlu.
  • Spring Boot hampir menyediakan validasi formulir sebagai fitur bawaan, dan cukup dengan annotation langsung bisa jalan.
• Saya menganggap Rails dan Django sama-sama framework hebat. Saya juga pernah membuat aplikasi yang mission-critical dengan Python. Tapi untuk pengembangan monolith berskala besar, saya cenderung ingin beralih ke Go karena merasa sistem tipe dan concurrency-nya lebih kuat. Masalahnya, ekosistem Go tidak memberikan framework ecosystem seperti Rails atau Django. Go memang terbaik untuk membuat alat networking atau CLI, tetapi untuk membangun aplikasi web full-stack dengan cepat, saya masih memilih Rails atau Django. Jadi saya belum benar-benar melihat klaim “Rails itu mati”.
  • Berkat tool seperti ogen, dari satu dokumen OpenAPI saja bisa generate otomatis router statis, validasi request/response, monitoring Prometheus, tracing OpenTelemetry, dan hampir semua fitur lain. Bisa juga generate kode client dan webhook; untuk autentikasi tinggal menambah satu fitur. Dengan sqlc dan pragma user_version SQLite, kode DB yang type-safe dan migrasi jadi lebih mudah. Menambahkan SQLite pun cukup dengan dua baris import di main.go. Template standar Go saja juga cukup untuk pemrosesan teks frontend, dan dengan embed asset statis mudah dimasukkan ke dalam binary. Deployment pun jadi sangat sederhana: cukup go build lalu memindahkan binary. Berkat tooling generate code, pengembangan backend Go jadi sangat cepat dan mudah.
  • Saya pun dulu juga ingin stack statically typed lengkap, tapi dibanding Go atau Rust, ASP.NET jauh lebih jelas jawabannya. Meskipun Microsoft gencar mempromosikan produk baru (misalnya Aspire.NET), justru .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) yang benar-benar batteries included dan andal. Perlu sedikit pergeseran mindset ke OOP dan DI, tapi bagi developer berpengalaman bukan masalah besar.
  • Masalah ekosistem Go bukan hanya mindset anti-framework, tetapi juga mindset anti-fitur modern. Java, Kotlin, Scala, C#, F#, dan lain-lain juga bagus untuk membuat alat networking atau CLI. Belakangan AOT Java pun pun tidak lagi terlalu bermasalah untuk lisensi komersial, dan .NET juga tidak lagi terikat ke Windows.
  • Saya merekomendasikan Encore. Terutama saat integrasi PaaS (seperti kombinasi NextJS+Vercel), dia sangat kuat. Mungkin sedikit berbeda dari prinsip inti Go, tapi untuk tim kecil atau one-person team ini pilihan yang sangat baik. Kalau perlu, bisa deploy langsung via BYOC atau membuat API layer sendiri pakai stdlib tanpa hambatan. Untuk frontend tetap perlu NextJS atau Remix/RR7, tapi integrasi sangat mudah berkat otomatisasi TypeScript client SDK. Encore juga punya integrasi PR dengan Vercel, jadi itu jadi nilai besar.
  • Kalau mau pengalaman seperti Django di Go, beego adalah yang paling bisa dipertimbangkan. Tapi saya merasa level kematangannya masih belum cukup untuk disebut setara Django atau Rails.
  • Saya sedang mengerjakan proyek Go sekarang dan benar-benar puas dengan kualitas kode yang rapi. AI sangat membantu melewati hambatan masuk ke framework. Meski begitu, untuk layanan yang langsung ke pelanggan saya merasa rails, sementara untuk alat internal/pekerjaan data, django terasa lebih intuitif.
  • Ruby juga bisa dilakukan type-check dengan Sorbet, dan fitur concurrency yang didukung Fiber hampir masuk tahap matang. Web server baru bernama Falcon sedang dibangun dengan Fiber. Memang belum sejajar dengan Puma, tapi sepertinya nanti akan siap dipakai secara serius.
  • Penulis bahasa Stanza menulis bahwa untuk framework sekuat Rails dibutuhkan prasyarat tertentu dari bahasa itu sendiri. Ketiadaan framework semacam itu di Go atau Java tampaknya hasil kerja sama keterbatasan bahasa (atau keterbatasan programmer).
  • Go sejak awal memang bukan untuk orientasi framework full-stack seperti Rails/Django.
  • Node/Express cocok untuk level pico service pengembang lokal, dan ASP.NET WebAPI/MVC menjadi backend yang ideal buat saya.
  • goravel dev juga layak dicoba.
• Kalau ikuti Rails Guides dari awal sampai akhir, kamu bisa langsung meluncurkan layanan nyata yang sudah mencakup autentikasi, caching, rich text, CI, dan DB. Tapi meski cocok untuk layanan besar seperti GitHub dan Airbnb, untuk startup awal menambahkan semua fitur ekstra/termasuk seperti autentikasi Devise, turbo, testing sejak awal malah bisa jadi pemborosan waktu. Turbo punya kelebihan mempercepat page load, tetapi karena bentrok dengan fitur Devise, justru bisa menambah waktu pengembangan. Kalau masih di tahap validasi ide sebelum rilis, kecuali aplikasi banking/healthcare, menunda testing atau CI pun tak jadi masalah besar. Penting untuk tidak tertipu bias default (memakai karena fiturnya ada), dan berani berkata, “saya tidak mau pakai itu sekarang.”
  • Kalau mau membangun SaaS, memulai dengan template Rails seperti Jumpstart Pro atau Bullet Train bisa hemat waktu pengembangan bertaburan bulan-bulan. Fitur seperti pembayaran, autentikasi, dan lain-lain sudah include sejak awal, dan extensibility-nya juga gampang.
  • Saya tidak setuju dengan pendapat bahwa testing tidak penting. Bahkan aplikasi kecil pun kalau punya kode test bisa menghemat waktu. CI juga biasanya selesai dengan satu file sekitar dua puluh baris—saya menyalinnya dari proyek sebelumnya.
  • CI itu justru faktor yang mempercepat pengembangan. Sebaiknya ditambahkan sejak awal proyek.
  • Saya penasaran dari sisi Flask/Express/Sinatra/Gradio/Hono, kapan saatnya beralih ke Rails.
• Rails terbaru memang terasa jauh lebih berkilau, jadi saya senang. Saya memelihara berbagai aplikasi selama 12 tahun sejak Rails 2.3, dan sekarang rails terasa seperti evolved Pokémon yang benar-benar berbeda. Berkat Rails Upgrade Guide yang sangat rapi, saya bisa meng-upgrade dengan baik tanpa refactor besar dalam satu kali jalan. Tidak selalu backward-compatible, tapi kelebihannya adalah semua perubahan didokumentasikan dengan jelas. ActiveStorage juga membuat fitur attachment file banyak berkembang; meski sempat susah saat migrasi dari Webpacker, dengan Import Maps sekarang terasa lebih mudah. Rencana saya tahun ini adalah upgrade ke 8.1.
  • Empat tahun lalu, saat klien dengan anggaran minim, saya memilih mempertahankan aplikasi Rails lama (era Ruby 2.3) meski harus menerima pay-cut. Hasilnya, saya sangat puas karena upgrade maupun penambahan fitur jadi benar-benar mudah.
• Saya mengembangkan proyek open-source Rails sendirian dan mendukung 120 ribu pengguna per bulan, jadi sangat sejalan dengan pernyataan di atas. Satu hal lagi, fitur attachment di ActiveStorage sangat hebat. Untuk deploy saya kebanyakan memakai Dokku, tetapi saya menunggu-nunggu untuk coba Kamal. Rails terus berkembang, dan Ruby makin cepat.
  • Kalau suka Dokku, penasaran apakah sudah coba Cloud Native Buildpacks. Alat ini bisa langsung membuat OCI image.
• Saya tidak terlalu banyak di web development saat belajar Ruby, jadi yang saya tahu kebanyakan Django saja. Penasaran, apa saja perbedaan jika kita bandingkan kedua framework ini.
  • Saya punya pengalaman panjang di kedua ekosistem (belum terlalu sering pakai rails belakangan ini). Django memang melekat ke Python, Rails ke Ruby/gem, jadi dampak ekosistem penting. Django admin CMS jelas lebih kuat dibanding Rails, dan banyak organisasi membangun semua CMS internalnya dengan django. Rails punya scaffolding CLI yang sangat besar, jadi fitur CRUD bisa dibangun sangat cepat. Rails punya tingkat abstraksi lebih tinggi dibanding Django dan karena strukturnya hampir ditentukan oleh Rails, di Django Anda harus menentukan jauh lebih banyak hal. Rails lebih menekankan DRY dan pencegahan duplikasi kode. Pihak yang mengutamakan intuisi ala Python bisa melihat magic Rails sebagai hal yang terlalu “aneh”, sementara yang dari Rails bisa menganggap pengulangan di Python terasa kasar. Pada dasarnya, kedua framework ini beda gaya.
  • Kalau saya bikin web app (produk consumer-facing), saya akan mengangkat rails dulu karena scaffolding dan go-to-market-nya lebih gampang (meski pengalaman saya di layanan skala besar belum ada). Kalau untuk alat internal, data work, atau geospasial, python/django lebih baik.
  • Perbedaan paling besar adalah python vs ruby. Ekosistem Python sangat besar, dan Django punya fitur autentikasi serta admin bawaan.
  • Menurut saya, pengalaman testing environment lebih baik di Rails. Rails menyediakan setup CI dan auto-generate test code.
  • Django Admin, berdasarkan pengalaman, terasa jauh lebih fleksibel dan mudah dipakai dibanding alternatif di sisi Ruby. Tapi untuk testing dan routing, Rails lebih baik dan konvensinya juga lebih kuat. Saya lebih suka ActiveRecord+arel daripada Django ORM. (Secara pribadi, menulis kode ruby terasa lebih menyenangkan daripada Python.)
  • Ruby tidak terlalu sulit dipelajari, dan Rails memberikan jauh lebih banyak struktur dan konvensi dibanding Django.
• Banyak orang punya keterikatan pada Rails yang hampir seperti rasa asmara; saya tidak bisa merasakan sampai sejauh itu, kadang sampai iri. Setiap bahasa atau framework punya penggemarnya sendiri, tapi semangat di komunitas Rails terasa lebih khusus.
  • Walau saya sering tidak nyaman dengan konvensi Rails, saya merasa sulit banget mencapai produktivitas serupa di backend JavaScript. Sebaliknya, saat mengurus kode Rails, saya melihat banyak kasus orang mengimplementasikan ulang fitur bawaan Rails (misalnya Active Job) dengan alasan yang tidak perlu. Mematuhi konvensi biasanya selalu lebih efisien.
• Setelah pakai SQLite di production, akhirnya saya menghadapi trouble karena migrasi. Contohnya, untuk menambah constraint NOT NULL ke kolom yang sudah ada, harus merewrite seluruh tabel lewat tabel sementara.
  • SQLite juga tidak punya ADD CONSTRAINT, dan tidak mendukung PL language atau stored proc sederhana, jadi akhirnya tetap harus bolak-balik ke bahasa host, terutama menyulitkan untuk bahasa yang statically typed.
  • Saya merasa Postgres adalah yang terbaik, jadi susah melepasnya. Tapi, langkah Rails menjadikan sqlite3 sebagai opsi first-class tetap kemajuan yang positif.
  • Rekomendasi default Rails kadang menyatakan sqlite sebagai pengganti redis, tetapi praktiknya cuma untuk memulai layanan kecil. Kalau nanti pindah ke DB lain, saya tidak akan menyarankan mulai dari sqlite karena migrasi selalu menyakitkan.
  • Di Rails, ActiveRecord validation bisa mengelola sebagian besar hal, tapi ada batas untuk merefleksikan constraint fundamental.
• Petunjuk instalasi Ruby cukup rumit. Setelah saya susun blog jekyll lagi setelah 15 tahun, saya agak kesulitan dengan penggunaan gem dan lainnya. Ada salah saya juga, tapi rasanya seandainya ditangani lebih mudah. Namun pengalaman itu tetap membuat saya makin ingin coba Ruby lagi.
  • Setup seharusnya mudah bagi siapa saja. Saya cepat mempelajari Jekyll, karena di environment saya sudah terpasang Ruby dan RubyGems.
• Kalau cuma mau pakai SQLite, litestack juga layak dipertimbangkan. Saya belum pernah memakainya langsung, tapi saya berencana berpindah proyek pribadi dari postgres ke litestack. Benchmark performance-nya sangat mengesankan.
  • Rails 8 memperkuat SQLite secara besar-besaran, jadi saya penasaran apakah litestack benar-benar masih diperlukan. Saya ingin tahu apa differentiator-nya.