Phát hành Rails 7.1

• Khi dùng config.load_defaults 7.1, cơ chế tuần tự hóa mặc định của ActiveSupport::MessageVerifier và ActiveSupport::MessageEncryptor được đổi từ Marshal sang ActiveSupport::JSON, và vẫn có thể tiếp tục đọc các message Marshal hiện có
• ActiveRecord::Base.serialize được thay đổi để mặc định không dùng YAML, và có thể khôi phục giá trị mặc định cũ bằng config.active_record.default_column_serializer = YAML
• Định dạng cache 7.1 mới được bổ sung và được dùng làm mặc định cho ứng dụng mới; với ứng dụng hiện có, có thể kích hoạt bằng config.load_defaults 7.1 hoặc config.active_support.cache_format_version = 7.1
  • Các mục được ghi bằng định dạng cache 6.1 hoặc 7.0 có thể được đọc trong định dạng 7.1
  • Khi rolling deploy Rails 7.1, cần giữ nguyên định dạng cache ở lần deploy đầu tiên, rồi bật định dạng cache 7.1 ở lần deploy sau
• Cơ chế tuần tự hóa :message_pack và :message_pack_allow_marshal được thêm vào MessageEncryptor, MessageVerifier, config.active_support.message_serializer, yêu cầu gem msgpack >= 1.7.0
• Ngăn rò rỉ giá trị bí mật trong inspect của ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration, các đối tượng mã hóa Active Record, đồng thời tăng cường bảo vệ XSS trong ActionView::Helpers và ERB::Util
• has_secure_password được bổ sung kiểm tra password_challenge và phương thức #{attribute}_salt, còn authenticate_by được thêm vào để giảm các cuộc tấn công liệt kê dựa trên timing theo sự tồn tại của tài khoản
• Active Record mở rộng hỗ trợ cho khóa chính tổng hợp và khóa ngoại tổng hợp, bao gồm cú pháp tuple where, sắp xếp batch theo khóa tổng hợp, và suy luận khóa chính tổng hợp từ schema
• Hỗ trợ PostgreSQL được bổ sung các lệnh migration để đổi tên enum, thêm giá trị, thay đổi giá trị; cùng với exclusion constraint, unique constraint, tùy chọn chỉ mục INCLUDE, và hỗ trợ chỉ mục NULLS [NOT] DISTINCT
• Adapter SQLite3 nêu rõ mức cải thiện hiệu năng trung bình 2× nhờ Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer, shared cache; đồng thời strict strings mode vô hiệu hóa double-quoted string literal được bật mặc định
• Việc lặp batch trên toàn bộ bảng trong Active Record mặc định dùng range iteration để cải thiện hiệu năng; trong bài test PostgreSQL với 10 triệu bản ghi, kết quả được đưa ra là querying 253s→30s, updating 288s→124s, deleting 268s→83s
• Connection pooling cho MemCacheStore và RedisCacheStore được bật mặc định; để tắt, cần chỉ định pool: false trong cấu hình cache store
• Bổ sung adapter cho database client Trilogy, cho phép dùng adapter: trilogy hoặc DATABASE_URL theo định dạng trilogy://
• Định dạng tag mặc định của ActiveRecord::QueryLogs được đổi sang định dạng SQLCommenter; có thể dùng định dạng cũ với config.active_record.query_log_tags_format = :legacy
• Các mục deprecated và bị loại bỏ bao gồm việc dùng singleton ActiveSupport::Deprecation, SafeBuffer#clone_empty, đối số rewhere của #merge, deferrable: true của add_foreign_key, TestFixtures#fixture_path, cùng nhiều cấu hình và API Active Record deprecated khác đã được dọn dẹp
• ActionView::TestCase.register_parser được thêm vào cho kiểm thử Action View để đăng ký parser cho kết quả render, với các parser mặc định là :html và :json

[GN⁺]

Ý kiến trên Hacker News

• Rails rất tuyệt, và hiện giờ nó còn tốt hơn bao giờ hết
  Giai đoạn đầu sự nghiệp tôi chủ yếu dùng Django và Laravel, sau đó chuyển sang làm các công việc frontend phổ biến ngày nay, và năm nay lại nhận một dự án Rails + Hotwire
  Tôi thật sự ngạc nhiên vì mọi thứ đã đơn giản đến mức nào, và thấy tiếc vì hầu hết chúng ta đã quên rằng mọi thứ có thể dễ dàng như vậy. Cũng đáng sợ ở chỗ những người mới bước vào ngành hiện nay có thể sẽ không được trải nghiệm sự đơn giản này
  Nếu bạn chưa từng dùng Rails, hoặc từng bỏ qua nó chỉ vì nghe những câu như “PHP xấu xí / Rails đã chết / JavaScript lộn xộn”, tôi khuyên bạn tạm thời bỏ ngoài tai lời người khác và thử dùng nó với một tâm thế cởi mở
  Nó có thể không phải lựa chọn tốt nhất cho môi trường có 1.000 kỹ sư cùng làm việc trên một repository, nhưng với đội ngũ nhỏ thì gần như không có đối thủ và vượt xa các lựa chọn khác. Nói thật thì Laravel có lẽ cũng tốt ở mức tương tự

  • Tôi cũng muốn thêm Phoenix LiveView vào đây
    Về tốc độ phát triển ban đầu, tôi nghĩ Rails luôn thắng. Các quy ước của nó rất chặt chẽ và được thiết kế tốt đến mức hầu như không có gì theo kịp. Laravel đang bắt kịp, nhưng tôi cho là vẫn chưa tới
    Tuy nhiên LiveView mở rộng tốt hơn theo mọi nghĩa. Nó cũng có nhiều thứ tích hợp sẵn như xác thực, truy cập cơ sở dữ liệu, hàng đợi tác vụ, mailer, bộ công cụ kiểm thử đầy đủ; gần như không cần tự viết JavaScript, và còn có BEAM, một máy ảo tuyệt vời
    Ít nhất thì tôi thấy mừng vì tất cả các dự án này đều đang cùng tham gia cuộc chiến “hãy lùi lại một bước”. Ở công ty tôi dùng React và Relay; dù đã dùng JavaScript frontend lâu năm và nghĩ mình cũng khá ổn, vẫn có quá nhiều rào cản phải vượt qua nên rất mệt
  • So với Django, thật thú vị là ít nhất hiện tại tôi không xem hai bên ngang hàng. Tôi tò mò liệu có lý do cụ thể nào khiến bạn thích Rails hơn Django không
  • Tôi thích Rails, nhưng ở nước tôi hầu như chẳng ai dùng, còn những công ty dùng nó thì gần như đều tìm lập trình viên cấp phù thủy
    Vì không kiếm được việc nên tôi cũng không tích lũy đủ kinh nghiệm, và cuối cùng bị các “phù thủy” đó vượt qua. Có tin tuyển dụng kiểu đó còn mở hơn 12 tháng
    Thay vào đó, vì đó là nơi có nhu cầu, tôi lại đang rải thêm JavaScript ra thế giới
  • Khá nhiều lập trình viên Rails mà tôi biết đã chuyển sang ember.js. Lý do là ember.js cũng là framework dựa trên quy ước, chứ không phải kiểu vô số plugin bên thứ ba liên tục bị vỡ
    Về mặt cấu trúc, tôi thích cách tiếp cận của ember-data. Có nhiều phần có thể tự động hóa trong các thao tác như left join/right join của tập dữ liệu, và cũng có mock server tích hợp
    Có điều có lẽ vì nó hoạt động quá tốt nên trông không “ngầu” bằng những thứ khác
    https://emberjs.com/

• Tôi đã nâng một ứng dụng Rails 7.0 dài 13.000 dòng lên 7.1, và ngoài khác biệt giữa 7.0 và 7.1[0], mọi thứ đều chạy sau khi chỉ đổi 1 dòng trong mã thiết lập test
  Xét về lộ trình nâng cấp dễ dàng thì tôi xem đây là một thành công. Giờ phần thú vị là refactor một số mã để dùng các tính năng mới của 7.1
  Nếu quan tâm, tôi cũng đã nâng ứng dụng ví dụ Rails / Docker lên 7.1: https://github.com/nickjj/docker-rails-example
  Rails 7.1 có kèm Dockerfile, nhưng vẫn còn nhiều lựa chọn có thể bổ sung, chẳng hạn dùng Docker Compose để tạo trải nghiệm chạy ngay được trong cả phát triển lẫn production, đồng thời bao gồm Postgres, Redis, Action Cable, Sidekiq, v.v.
  [0]: https://railsdiff.org/7.0.8/7.1.0

• Đang cố nâng một codebase Rails 6 khá lớn, có gắn rất nhiều React, lên theo cách “không” JavaScript mới dùng Hotwire. Chúc tôi may mắn nhé
  Rails rất tuyệt khi bạn giữ nguyên các mặc định, nhưng hễ bước ra khỏi các mặc định đó là bước vào vùng đất đau khổ

  • Tôi đang làm việc trên một codebase Rails 7 tương đối gần đây. Ban đầu bắt đầu dùng Stimulus, nhưng vì vài lý do đang cân nhắc chuyển sang React
    Nếu muốn tuyển kỹ sư frontend thì nguồn ứng viên React lớn hơn vài bậc. Việc tìm các gói JavaScript thuần cho những tác vụ thông thường rồi bọc chúng bằng Stimulus controller cũng ngày càng khó hơn so với tìm gói React
    Stimulus cũng không thực sự cung cấp cách viết unit test cho controller. Với React thì có thể dùng jest và react-test-renderer như thường lệ
    Hơn nữa, tranh cãi gần đây về Turbo TypeScript không đem lại niềm tin vào việc vận hành dài hạn của hệ sinh thái Hotwire
    Vẫn chưa đưa ra quyết định. Rõ ràng việc Stimulus mang cảm giác như một cách rất “đúng kiểu Rails” để viết code frontend là một điểm cộng, đặc biệt với các nhóm nhỏ vốn đã quen Rails
  • Câu “Rails tốt nếu giữ mặc định, đau khổ nếu đi chệch khỏi đó” đúng với mọi framework
    Nếu ứng dụng khá đơn giản và khớp tốt với cách làm của framework thì framework rất tuyệt. Nếu cần cấu hình phức tạp và linh hoạt hơn, bạn nên nhìn sang thư viện
  • Tôi đã mất niềm tin vào tích hợp JavaScript của Rails
    Giờ thì hoặc render phía server bằng slim, hoặc làm API-only và tách frontend riêng
    Rails đã đổi hướng quá nhiều lần khi cố làm JavaScript: CoffeeScript, tiền biên dịch asset, webpack, v.v.
  • Tôi không khuyên chuyển frontend React hiện có sang Hotwire cùng lúc với việc nâng cấp chính Rails. Theo tôi, tốt hơn là trước hết nâng độc lập lên Rails 7.1
    Nhân tiện, cách xử lý JavaScript cho ứng dụng một trang trong Rails 7+ cũng hợp lý hơn trước rất nhiều. Về cơ bản, bạn có thể dùng bất kỳ công cụ build nào mình muốn tách khỏi ứng dụng Rails
    Trong lúc phát triển, bạn phải chạy thứ như yarn build --watch cùng với rails s, nhưng cá nhân tôi thấy không tệ và đơn giản hơn nhiều
    Công ty chúng tôi làm phần mềm tự động hóa nâng cấp Rails, và cũng cung cấp dịch vụ trọn gói làm hộ việc nâng cấp Rails. Nếu quan tâm, có thể liên hệ steve (at) infield.ai hoặc tạo kế hoạch nâng cấp Rails miễn phí tại https://app.infield.ai/users/sign_up. Không cần thẻ tín dụng
    Xem thêm chi tiết tại https://docs.infield.ai/docs/creating-an-upgrade-path
  • Khuyên nên thử https://vite-ruby.netlify.app/guide/rails.html
    Với tôi thì gần như khớp ngay như một thay thế cho webpack

• Tôi thích Rails và đã dùng không thường xuyên từ thời Rails 2
  Đây là một framework rất tốt, và với người như tôi, thỉnh thoảng cần dựng một website, thì nó thật sự là con đường ít trở ngại nhất
  Tuy vậy, quá trình thiết lập để chạy Rails trên laptop mới khá khổ sở. Cần node, rồi từ đó cần npm. Là backend developer nên tôi không rõ phải thiết lập node thế nào, theo thứ tự nào
  Vì không làm thường xuyên nên lần nào cũng như đánh vật. Cuối cùng cũng làm được, nhưng tôi luôn không chắc vì sao rốt cuộc mọi thứ lại khớp với nhau
  Giá mà có một trình cài đặt chỉnh mọi thứ cần thiết cùng lúc để rails cứ thế chạy được. Trình cài rvm thiết lập rails trên ruby, nhưng không thiết lập cả hệ thống node bên dưới

  • Có một trình quản lý phiên bản tên asdf khá tốt để quản lý nodejs. Ruby thì tôi chưa thử
    https://asdf-vm.com/
  • Tôi hiểu câu “là backend developer nên không biết thiết lập node”
    Node chủ yếu được biết đến như công cụ frontend và Rails cũng dùng nó cho mục đích đó, nhưng theo tôi nhớ thì ít nhất ban đầu Node được tạo ra để đưa runtime JavaScript sang backend
    Ngay cả không có trình quản lý gói, trên Windows thì chỉ là node.exe; theo tôi biết chỉ cần tải npm về, giải nén, rồi đưa node và npm vào biến môi trường PATH
  • Toàn bộ tiền đề của Rails 7 chính là loại bỏ phụ thuộc vào node
  • Tôi chưa từng dùng Rails nên tò mò, muốn biết vì sao “Ruby on Rails” lại cần nodejs
    Và cài node khá dễ. Thật ra là quá dễ. Tôi ước nó khó hơn nhiều và cần có bằng cấp
  • Cộng đồng Ruby/Rails thuộc loại tốt và thân thiện nhất mà tôi từng thấy. Nhưng điều tệ nhất trong đó chắc chắn là sự ghét bỏ JavaScript
    JavaScript cũng chỉ là một công cụ như mọi thứ khác. Dù thích hay không, nó là một công cụ rất quan trọng, và dù thích hay không, nó sẽ còn tồn tại lâu dài
    Nếu cởi mở hơn một chút và ít nhất học những điều cơ bản, công việc sẽ dễ hơn

• Mong Rails + HTMX và cách chỉ rắc thêm một chút JavaScript cho những trang có tính tương tác rất cao sẽ hồi sinh
  Dùng Rails cùng Slim/HAML thật sự rất thú vị. Nếu muốn, cũng có thể dùng thư viện như ViewComponents để render từng phần dễ hơn. Thêm web components vào đó thì có thể tạo các trang khá tương tác, và nếu một trang cụ thể thật sự cần thì vẫn có thể dùng React
  HATEOAS giúp giảm đáng kể độ phức tạp của ứng dụng. Dù vậy nếu cần API, việc phản hồi các MIME type khác nhau cũng rất dễ, và nếu muốn còn có thể dùng chung cùng một endpoint
  Theo kinh nghiệm, phần lớn ứng dụng dùng React thật ra hoàn toàn không cần React. Chúng dùng React chỉ vì vài menu popup
  Vì vậy, nếu các ứng dụng lớn không dùng React, hoặc chỉ dùng rất ít React, bắt đầu xuất hiện, tôi mong sẽ có người nhận ra ứng dụng của chúng ta ngày nay phức tạp không cần thiết đến mức nào
  Thế mà tôi đã thấy người ta nói “ai cũng dùng React nên phải chuyển sang React”. Thở dài
  Mơ thì vẫn được mà

• Thông báo chính thức ở đây: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Có thêm một chút chi tiết ở mức tổng quan, và rất háo hức muốn thử một số thay đổi mới. Đặc biệt các phương thức truy vấn bất đồng bộ mới có vẻ sẽ khá hữu ích để cải thiện hiệu năng nhanh chóng

• Rails ở backend chưa nhận được sự đánh giá xứng đáng
  Tuy nhiên phía frontend thì đã lộn xộn trong một thời gian rất dài

  • Tôi không phản đối việc “phía frontend đã lộn xộn trong một thời gian dài”, nhưng bản thân frontend cũng đã lộn xộn từ lâu rồi
    Bây giờ làm việc với Rails 7.1 + Hotwired + Importmaps rất thú vị
    Nhưng đã phải chờ cho đến khi trình duyệt hỗ trợ tối thiểu ES6 và Import Maps đủ tốt
    Nếu nhìn ngày của bài này https://web.dev/import-maps-in-all-modern-browsers/, họ công bố vào ngày 28/03/2023 rằng importmaps có thể dùng trên mọi trình duyệt hiện đại
    Vì vậy cho đến giờ vẫn không có cách nào tránh Webpack, Yarn và các công cụ hỗ trợ JavaScript khác
    Nay đã có importmaps và hỗ trợ ES6 của trình duyệt cũng đủ tốt https://caniuse.com/?search=es6, nên có thể dùng JavaScript hiện đại mà hầu như không cần thêm công cụ nào
  • Đồng ý. Vậy các lựa chọn ở đây là gì? Rails ở chế độ chỉ API à?
  • Tôi thích các tính năng Hotwire mới. Tò mò không biết bạn không thích điều gì ở frontend

• Vài tuần trước một người bạn đùa rằng: “Nếu một bản phát hành Rails được công bố mà cậu không gửi PR nâng cấp, thì chuyện đó có thật sự xảy ra không?”
  Rồi, giờ đến lúc gửi PR. Dù có phải xếp nó sau PR 7.0 đã nằm chờ suốt mấy tháng

• Theo kinh nghiệm, nhiều đội gặp khó khăn khi xây dựng codebase gọn gàng với ActiveRecord

• Mong đừng ném đá, nhưng tôi vẫn đang dùng Rails 4.2 và hài lòng với nó
  Nó cung cấp đủ mọi thứ tôi cần cho các công việc SaaS backend không có hoặc ít JavaScript mà tôi tự làm hoặc làm cho các công ty B2B, và chạy được cả trên VPS cấu hình thấp
  Nếu có thời gian trả lời, tôi tò mò vì sao nên nâng cấp

  • Tôi cũng dùng phiên bản cũ. Trước hết nên kiểm tra xem có thể nâng lên phiên bản patch/minor mới nhất không
    Vấn đề cốt lõi của các phiên bản cũ là lỗ hổng trong các gem liên quan. Ví dụ nokogiri có thể không nâng lên được nếu không nâng major Rails
    Tuy nhiên đa số app không làm những việc như phân tích XML phức tạp, nên khá nhiều lỗ hổng không áp dụng. Vì vậy cần một chút bảo trì để kiểm tra xem có an toàn không. Cũng thường phải thêm monkey patch để tránh lỗi
    Nâng cấp sẽ cải thiện bảo mật và giảm thời gian bảo trì. Nhưng cũng cần cân nhắc chi phí nâng cấp liên tục. Một yếu tố khác là các phiên bản mới có thể hỗ trợ Ruby nhanh hơn
    Thông thường khi tạo app Rails tôi dùng bản phát hành mới nhất, nhưng sau đó không nâng các phiên bản Rails nữa trừ khi app rất phổ biến hoặc quá cũ đến mức có thứ gì đó không chạy trên hệ thống mới
  • Bạn nên nâng cấp vì bảo mật