Rilis Rails 7.1

• Saat menggunakan config.load_defaults 7.1, serialisasi default ActiveSupport::MessageVerifier dan ActiveSupport::MessageEncryptor berubah dari Marshal ke ActiveSupport::JSON, dan pesan Marshal lama tetap dapat dibaca
• ActiveRecord::Base.serialize diubah agar secara default tidak menggunakan YAML, dan nilai default lama dapat dipulihkan dengan config.active_record.default_column_serializer = YAML
• Format cache 7.1 baru ditambahkan dan digunakan sebagai nilai default untuk aplikasi baru, sementara aplikasi lama dapat mengaktifkannya dengan config.load_defaults 7.1 atau config.active_support.cache_format_version = 7.1
  • Entri yang ditulis dengan format cache 6.1 atau 7.0 dapat dibaca dalam format 7.1
  • Dalam rolling deployment Rails 7.1, format cache harus dipertahankan pada deployment pertama, lalu format cache 7.1 diaktifkan pada deployment berikutnya
• Serialisasi :message_pack dan :message_pack_allow_marshal ditambahkan ke MessageEncryptor, MessageVerifier, dan config.active_support.message_serializer, serta memerlukan gem msgpack >= 1.7.0
• inspect pada ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration, dan objek enkripsi Active Record kini mencegah kebocoran nilai rahasia, serta perlindungan XSS pada ActionView::Helpers dan ERB::Util diperkuat
• has_secure_password kini menambahkan validasi password_challenge dan metode #{attribute}_salt, dan authenticate_by ditambahkan untuk mengurangi serangan enumerasi berbasis timing berdasarkan ada atau tidaknya akun
• Dukungan terkait composite primary key dan composite foreign key di Active Record diperluas, termasuk dukungan sintaks tuple where, pengurutan batch dengan composite key, dan inferensi composite primary key dari skema
• Dukungan PostgreSQL ditambah dengan perintah migrasi untuk mengganti nama enum, menambah nilai enum, mengubah nilai enum, exclusion constraint, unique constraint, opsi indeks INCLUDE, dan dukungan indeks NULLS [NOT] DISTINCT
• Adapter SQLite3 mencatat peningkatan performa rata-rata 2× berkat pengaturan Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer, dan shared cache, serta strict strings mode yang menonaktifkan double-quoted string literal kini aktif secara default
• Iterasi batch seluruh tabel di Active Record kini secara default menggunakan range iteration untuk meningkatkan performa, dengan hasil uji PostgreSQL 10 juta record: querying 253s→30s, updating 288s→124s, deleting 268s→83s
• Connection pooling pada MemCacheStore dan RedisCacheStore kini aktif secara default, dan untuk menonaktifkannya perlu menetapkan pool: false pada konfigurasi cache store
• Adapter untuk klien database Trilogy ditambahkan sehingga adapter: trilogy atau DATABASE_URL berformat trilogy:// dapat digunakan
• Format tag default ActiveRecord::QueryLogs diubah ke format SQLCommenter, dan format lama tetap dapat digunakan dengan config.active_record.query_log_tags_format = :legacy
• Item deprecation dan removal mencakup penggunaan singleton ActiveSupport::Deprecation, SafeBuffer#clone_empty, argumen rewhere pada #merge, deferrable: true pada add_foreign_key, TestFixtures#fixture_path, serta pembersihan berbagai pengaturan dan API Active Record yang deprecated
• ActionView::TestCase.register_parser ditambahkan ke pengujian Action View agar parser hasil rendering dapat didaftarkan, dengan parser bawaan :html dan :json

[GN⁺]

Komentar di Hacker News

• Rails itu luar biasa, dan sekarang lebih baik daripada sebelumnya
  Di awal karier, saya terutama memakai Django dan Laravel, lalu kemudian beralih ke pekerjaan frontend yang umum sekarang, dan tahun ini kembali menangani proyek Rails + Hotwire
  Saya benar-benar terkejut melihat betapa sederhananya semuanya sekarang, dan sayang sekali kebanyakan orang sudah lupa bahwa sesuatu bisa semudah ini. Menakutkan juga bahwa orang-orang yang masuk ke industri sekarang mungkin tidak pernah mengalami kesederhanaan seperti ini
  Kalau belum pernah mencoba Rails, atau berhenti hanya karena mendengar hal seperti “PHP itu jelek / Rails sudah mati / JavaScript itu berantakan”, saya sarankan untuk sejenak mengabaikan omongan orang lain dan mencobanya dengan pikiran terbuka
  Mungkin bukan pilihan terbaik untuk lingkungan dengan 1.000 engineer bekerja di repositori yang sama, tetapi untuk tim kecil tidak ada tandingannya dan jauh di depan yang lain. Sejujurnya, Laravel mungkin juga hampir sama bagusnya

  • Saya juga ingin memasukkan Phoenix LiveView di sini
    Dalam hal kecepatan pengembangan awal, menurut saya Rails selalu menang. Konvensinya sangat rapat dan dirancang dengan baik sehingga hampir tidak ada yang bisa menyamai. Laravel memang mulai mengejar, tetapi menurut saya belum sampai di sana
    Namun LiveView lebih mudah diskalakan dalam segala arti. Banyak hal tersedia bawaan seperti autentikasi, akses database, antrean pekerjaan, mailer, alat pengujian lengkap, dan hampir tidak perlu menulis JavaScript langsung, ditambah ada BEAM, virtual machine yang hebat
    Setidaknya saya senang semua proyek seperti ini memperjuangkan gagasan “mari mundur selangkah”. Di kantor saya memakai React dan Relay, dan meski sudah lama memakai JavaScript frontend dan merasa cukup mampu, terlalu banyak rintangan yang harus dilewati sampai melelahkan
  • Dibandingkan dengan Django, menarik bahwa setidaknya saat ini Anda tidak melihat keduanya setara. Saya penasaran apakah ada alasan spesifik mengapa Anda lebih memilih Rails daripada Django
  • Saya suka Rails, tetapi di negara saya hampir tidak ada yang memakainya, dan perusahaan yang memakainya hampir selalu mencari developer tingkat penyihir
    Karena tidak bisa mendapatkan pekerjaan, saya juga tidak bisa mengumpulkan cukup pengalaman, dan pada akhirnya kalah bersaing dengan para penyihir itu. Lowongan seperti itu kadang tetap terbuka lebih dari 12 bulan
    Sebagai gantinya, karena di sanalah ada permintaan, saya ikut menyebarkan lebih banyak JavaScript ke dunia
  • Cukup banyak developer Rails yang saya kenal beralih ke ember.js. Alasannya, ember.js juga merupakan framework berbasis konvensi, bukan framework yang membuat banyak plugin pihak ketiga terus-menerus rusak
    Secara struktural, saya suka pendekatan ember-data. Banyak hal seperti left join/right join pada dataset yang bisa diotomatisasi, dan ada mock server terintegrasi juga
    Namun mungkin karena terlalu bekerja dengan baik, ia tidak terlihat sekeren yang lain
    https://emberjs.com/

• Saya menaikkan aplikasi Rails 7.0 berisi 13.000 baris ke 7.1, dan selain perbedaan antara 7.0 dan 7.1[0], semuanya berjalan hanya dengan mengubah 1 baris kode konfigurasi test
  Dari sisi jalur upgrade yang mudah, menurut saya ini sukses. Sekarang bagian menariknya adalah me-refactor sebagian kode agar memakai fitur baru di 7.1
  Kalau tertarik, saya juga sudah menaikkan aplikasi contoh Rails / Docker ke 7.1 https://github.com/nickjj/docker-rails-example
  Rails 7.1 memang menyertakan Dockerfile, tetapi masih ada banyak opsi yang bisa ditambahkan, seperti memakai Docker Compose untuk membuat pengalaman yang langsung berjalan di development dan production, serta menyertakan Postgres, Redis, Action Cable, Sidekiq, dan sebagainya
  [0]: https://railsdiff.org/7.0.8/7.1.0

• Sedang mencoba memindahkan codebase Rails 6 yang cukup besar dan penuh React ke pendekatan “non-” JavaScript baru yang memakai Hotwire. Doakan berhasil
  Rails luar biasa kalau tetap mengikuti default-nya, tetapi begitu keluar dari default itu, ia menjadi tanah penuh penderitaan

  • Saya bekerja di codebase Rails 7 yang relatif baru. Awalnya kami mulai memakai Stimulus, tetapi karena beberapa alasan kami sedang mempertimbangkan beralih ke React
    Untuk merekrut engineer frontend, kumpulan kandidat React beberapa orde lebih besar. Mencari paket JavaScript vanilla untuk tugas umum lalu membungkusnya dengan controller Stimulus juga makin sulit dibanding mencari paket React
    Stimulus juga tidak benar-benar menyediakan cara untuk menulis unit test controller. Di React, kita bisa memakai jest dan react-test-renderer seperti biasa
    Selain itu, kontroversi Turbo TypeScript baru-baru ini tidak memberi kepercayaan terhadap keberlangsungan jangka panjang ekosistem Hotwire
    Kami belum mengambil keputusan. Fakta bahwa Stimulus terasa seperti cara yang sangat ala Rails untuk menulis kode frontend jelas merupakan kelebihan, terutama untuk tim kecil yang sudah akrab dengan Rails
  • Pernyataan “Rails bagus kalau mengikuti default, menyakitkan kalau menyimpang” berlaku untuk semua framework
    Jika aplikasi cukup sederhana dan cocok dengan cara kerja framework, framework itu hebat. Jika membutuhkan konfigurasi yang lebih kompleks dan fleksibel, sebaiknya melihat library
  • Saya kehilangan kepercayaan pada integrasi JavaScript di Rails
    Sekarang saya melakukan server-side rendering dengan slim, atau membuatnya API-only dan memisahkan frontend
    Rails terlalu sering berganti arah untuk JavaScript: CoffeeScript, asset precompile, webpack, dan sebagainya
  • Saya tidak akan menyarankan memindahkan frontend React yang sudah ada ke Hotwire bersamaan dengan upgrade Rails itu sendiri. Menurut saya lebih baik naik dulu secara terpisah ke Rails 7.1
    Sebagai catatan, cara menangani JavaScript aplikasi single-page di Rails 7+ juga jauh lebih masuk akal daripada sebelumnya. Pada dasarnya Anda bisa memakai build tool apa pun yang diinginkan secara terpisah dari aplikasi Rails
    Saat pengembangan, Anda memang harus menjalankan sesuatu seperti yarn build --watch bersamaan dengan rails s, tetapi secara pribadi menurut saya itu tidak buruk dan menjadi jauh lebih sederhana
    Perusahaan kami membuat software untuk mengotomatiskan upgrade Rails, dan juga menyediakan layanan penuh yang mengerjakan upgrade Rails untuk Anda. Jika tertarik, hubungi steve (at) infield.ai atau buat rencana upgrade Rails gratis di https://app.infield.ai/users/sign_up. Tidak perlu kartu kredit
    Untuk detailnya, lihat https://docs.infield.ai/docs/creating-an-upgrade-path
  • Saya sarankan mencoba https://vite-ruby.netlify.app/guide/rails.html
    Dalam kasus saya, ini langsung cocok hampir seperti pengganti webpack

• Saya menyukai Rails dan sudah memakainya sesekali sejak Rails 2
  Ini framework yang sangat bagus, dan bagi orang seperti saya yang kadang perlu menjalankan situs web, ini benar-benar jalur dengan hambatan paling kecil
  Namun proses menyiapkan laptop baru agar bisa menjalankan Rails itu menyiksa. Perlu node, lalu berarti perlu npm juga. Karena saya developer backend, saya tidak terlalu tahu cara menyiapkan node atau urutan yang benar
  Karena bukan hal yang sering saya lakukan, setiap kali terasa seperti pertarungan. Pada akhirnya memang berhasil, tetapi saya selalu tidak yakin kenapa semuanya akhirnya bisa cocok
  Saya berharap ada installer yang memasang semua yang dibutuhkan sekaligus sehingga rails langsung berjalan. Installer rvm menyiapkan rails di atas ruby, tetapi tidak menyiapkan sistem node di bawahnya

  • Version manager bernama asdf bagus untuk mengelola nodejs. Saya belum pernah memakainya untuk Ruby
    https://asdf-vm.com/
  • Saya paham maksud “karena developer backend, saya tidak tahu cara setup node”
    Node terutama dikenal sebagai tool frontend dan Rails juga memakainya untuk tujuan itu, tetapi seingat saya Node setidaknya awalnya dibuat untuk membawa runtime JavaScript ke backend
    Bahkan tanpa package manager, di Windows itu pada dasarnya hanya node.exe; setahu saya tinggal unduh dan ekstrak npm, lalu masukkan node dan npm ke variabel lingkungan PATH
  • Seluruh premis Rails 7 justru menghapus dependensi node
  • Saya belum pernah mencoba Rails, jadi penasaran: mengapa “Ruby on Rails” membutuhkan nodejs?
    Dan instalasi node itu cukup mudah. Malah terlalu mudah. Saya berharap jauh lebih sulit dan membutuhkan gelar
  • Komunitas Ruby/Rails termasuk yang terbaik dan paling ramah yang pernah saya lihat. Namun bagian terburuknya jelas adalah kebencian terhadap JavaScript
    JavaScript hanyalah alat seperti yang lain. Suka atau tidak, ini alat yang sangat penting, dan suka atau tidak, akan tetap ada untuk waktu lama
    Jika sedikit lebih terbuka dan setidaknya mempelajari dasar-dasarnya, pekerjaan akan menjadi lebih mudah

• Saya berharap Rails + HTMX, dengan sedikit JavaScript hanya untuk halaman yang sangat interaktif, kembali bangkit
  Memakai Rails bersama Slim/HAML benar-benar menyenangkan. Jika mau, library seperti ViewComponents bisa membuat partial rendering lebih mudah. Tambahkan web components, dan Anda bisa membuat halaman yang cukup interaktif; kalau benar-benar perlu di halaman tertentu, React juga bisa dipakai
  HATEOAS sangat mengurangi kompleksitas aplikasi. Meski begitu, jika membutuhkan API, merespons MIME type yang berbeda juga sangat mudah, dan jika mau bisa berbagi endpoint yang sama
  Berdasarkan pengalaman saya, sebagian besar aplikasi yang memakai React sebenarnya sama sekali tidak membutuhkan React. Mereka memakai React hanya karena beberapa menu popup
  Jadi jika mulai bermunculan aplikasi besar tanpa React, atau hanya memakai React sangat sedikit, saya berharap ada orang yang menyadari betapa tidak perlunya kompleksitas aplikasi kita saat ini
  Namun saya sudah melihat argumen “semua orang memakai React, jadi kita harus pindah ke React”. Bikin menghela napas
  Ya, boleh saja bermimpi

• Pengumuman resminya ada di sini: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Ada sedikit lebih banyak detail tingkat tinggi, dan saya menantikan untuk mencoba sebagian perubahan barunya. Terutama metode kueri asinkron baru sepertinya cukup berguna untuk peningkatan performa cepat

• Rails di backend belum mendapatkan apresiasi yang semestinya
  Namun sisi frontend-nya memang sangat berantakan untuk waktu yang sangat lama

  • Saya tidak menolak bahwa “sisi frontend-nya sudah lama berantakan”, tetapi frontend itu sendiri juga sudah lama berantakan
    Sekarang bekerja dengan kombinasi Rails 7.1 + Hotwired + Importmaps terasa menyenangkan
    Namun kita memang harus menunggu sampai dukungan ES6 dan Import Maps setidaknya cukup baik di browser
    Kalau melihat tanggal artikel ini, https://web.dev/import-maps-in-all-modern-browsers/ mengumumkan bahwa importmaps bisa digunakan di semua browser modern pada 28 Maret 2023
    Jadi sampai sekarang tidak ada cara untuk menghindari Webpack, Yarn, dan berbagai alat bantu JavaScript lainnya
    Sekarang sudah ada importmaps dan dukungan ES6 di browser juga sudah cukup baik, jadi https://caniuse.com/?search=es6, kita bisa memakai JavaScript modern dengan hampir tanpa alat tambahan
  • Setuju. Apa pilihannya di sini? Rails dalam mode khusus API?
  • Saya suka fitur Hotwire yang baru. Penasaran bagian frontend mana yang tidak disukai

• Beberapa minggu lalu seorang teman bercanda, “Kalau rilis Rails sudah diumumkan tapi kamu belum mengajukan PR upgrade, apakah itu benar-benar terjadi?”
  Nah, sekarang saatnya mengajukan PR. Sekalipun harus ditumpuk di belakang PR 7.0 yang sudah menunggu berbulan-bulan

• Dari pengalaman, banyak tim kesulitan membuat codebase yang rapi dengan ActiveRecord

• Jangan diserang ya, tapi saya masih memakai Rails 4.2 dan puas dengannya
  Ini menyediakan semua yang saya butuhkan untuk pekerjaan SaaS backend tanpa JavaScript atau dengan sedikit JavaScript, baik yang saya kerjakan sendiri maupun untuk perusahaan B2B, dan berjalan juga di VPS spesifikasi rendah
  Kalau ada waktu untuk menjawab, saya penasaran kenapa saya harus upgrade

  • Saya juga memakai versi lama. Pertama-tama perlu dicek apakah bisa dinaikkan ke versi patch/minor terbaru
    Masalah utama versi lama adalah kerentanan pada gem yang terhubung. Misalnya, nokogiri mungkin tidak bisa dinaikkan tanpa upgrade major Rails
    Namun kebanyakan aplikasi, misalnya, tidak melakukan parsing XML yang kompleks, jadi cukup banyak kerentanan tidak relevan. Karena itu perlu sedikit maintenance untuk memastikan aman. Sering juga perlu memasang monkey patch untuk mencegah bug
    Dengan upgrade, keamanan membaik dan waktu maintenance berkurang. Namun biaya upgrade yang terus-menerus juga harus dipertimbangkan. Faktor lainnya adalah versi baru bisa mendapat dukungan Ruby yang lebih cepat
    Biasanya saat membuat aplikasi Rails saya memakai rilis terbaru, tetapi setelah itu saya tidak menaikkan versi Rails kecuali aplikasinya populer atau sangat tua sampai ada sesuatu yang tidak berjalan di sistem baru
  • Harus upgrade karena keamanan