- Khi làm ứng dụng quản lý setlist (setlist.rocks) cho ban nhạc, tác giả đã lần nữa khám phá lại niềm vui của việc phát triển bằng Ruby on Rails sau một thời gian dài
- Rails 8 mới nhất vẫn giữ cấu trúc MVC truyền thống nhưng đã được hiện đại hóa với frontend “no-build” dựa trên Hotwire (Stimulus·Turbo), cùng Solid Cache/Queue/Cable
- SQLite đã được tối ưu đủ để phù hợp cho dịch vụ thực tế chỉ với cấu hình mặc định, và công cụ triển khai Kamal giúp việc triển khai không gián đoạn dựa trên container trở nên đơn giản hơn
- Nhờ triết lý “Convention over Configuration” của Rails và hệ sinh thái gem phong phú, có thể triển khai nhanh từ ý tưởng đến prototype
- Dù mức độ phổ biến của Ruby và Rails đã giảm so với trước, đây vẫn là một framework OSS trưởng thành và nhất quán mang lại niềm vui khi phát triển
Side project và sự trở lại với Rails
- Để quản lý setlist và ghi chú bài hát cho ban nhạc, tác giả đã tự phát triển một web app, hướng tới cách làm hiệu quả hơn so với spreadsheet hay chat hiện có
- Trong quá trình phát triển, tác giả một lần nữa cảm nhận được sự đơn giản và năng suất của Rails, và cho biết đã tìm lại được “niềm vui thuần túy của việc lập trình” so với hệ sinh thái web phức tạp gần đây
- Ruby vẫn được đánh giá là ngôn ngữ có cú pháp tự nhiên và khả năng biểu đạt cao, giúp dễ dàng chuyển suy nghĩ thành mã nguồn
- Theo khảo sát Stack Overflow 2025, mức độ phổ biến của Ruby và Rails đã giảm, nhưng chúng vẫn được ưa chuộng trong các dự án cá nhân
Thay đổi của Rails 8 và frontend
- Rails 8 vẫn giữ cấu trúc MVC hiện có, đồng thời cung cấp tích hợp frontend dựa trên Hotwire (Stimulus·Turbo)
- Turbo chặn việc nhấp liên kết và gửi form để mang lại độ phản hồi ở mức SPA
- Stimulus chỉ thêm hành vi JS vào những phần cần thiết, cho phép xây dựng UI tương tác với lượng JavaScript tối thiểu
- Với Importmap, có thể tải trực tiếp thư viện JS từ CDN mà không cần Webpack hay npm
- Tác giả có dùng công cụ AI để tạo UI, nhưng cũng bộc lộ sự trăn trở giữa sáng tạo và tính nghệ thuật của mã nguồn
Workflow phát triển và năng suất
- Với triết lý “Convention over Configuration” của Rails, có thể nhanh chóng cấu hình model, routing, controller và view
- Ví dụ minh họa quá trình tạo model
Tag, tự động hóa RESTful routing và xử lý phản hồi JSON
- Có thể prototype nhanh nhờ template ERB và live reload
- Nhờ hệ sinh thái gem phong phú, có thể dễ dàng tích hợp nhiều tính năng như CSV, PDF
Cải tiến backend: dòng Solid* và SQLite
- Solid Cache/Queue/Cable được tích hợp mặc định trong Rails 8, cho phép xử lý cache, job queue và websocket mà không cần Redis
- Solid Cache dùng caching dựa trên DB để tiết kiệm RAM và đơn giản hóa hệ thống
- Solid Queue quản lý tác vụ nền dựa trên DB, có thể chạy chỉ với thiết lập
SOLID_QUEUE_IN_PUMA=1
- Solid Cable hỗ trợ tính năng thời gian thực với adapter Action Cable dựa trên DB
- Với thiết lập
pragmas: trong database.yml, SQLite mặc định áp dụng tối ưu như chế độ WAL và đồng bộ NORMAL
- Có thể sử dụng thực tế trong môi trường production quy mô nhỏ mà không cần máy chủ DB riêng
Tự động hóa triển khai và Kamal
- Nhắc lại sự phức tạp của cách triển khai trước đây dựa trên Capistrano và Ansible, tác giả giới thiệu Kamal là công cụ triển khai mặc định của Rails 8
- Tự động hóa toàn bộ quy trình build container → push → triển khai lên server → health check → chuyển đổi không gián đoạn
- kamal-proxy đảm nhiệm việc chuyển lưu lượng và xử lý SSL
- Hỗ trợ quản lý secret an toàn dựa trên biến môi trường thông qua tệp
.kamal/secrets
- Kết hợp với GitLab CI, có thể triển khai chỉ bằng
git push, tái hiện sự đơn giản trước đây của Heroku
Xác thực và các tính năng khác
- Rails 8 cung cấp auth generator tích hợp sẵn, giúp xây dựng hệ thống xác thực đơn giản hơn so với Devise
- Devise vẫn hữu ích nhờ tính năng phong phú và tài liệu đầy đủ, nhưng sự đơn giản của hệ thống xác thực mặc định trong Rails cũng được đánh giá cao
Hiện trạng và tính bền vững của hệ sinh thái Rails
- Dù mức độ phổ biến của Ruby và Rails đã giảm, các dịch vụ lớn như Shopify·Basecamp·SoundCloud·GitHub vẫn đang sử dụng
- Nhiều gem đã bước vào giai đoạn bảo trì, nhưng Rails vẫn duy trì chu kỳ phát hành đều đặn hằng năm
- Được đánh giá là “một framework mà dù lượng lập trình viên mới tham gia đã giảm, người ta vẫn có thể phát triển đầy hứng thú”
Kết luận
- Rails tuy có khoảng cách với các xu hướng mới nhất, nhưng được nhấn mạnh là công cụ giúp lấy lại niềm vui và sự đơn giản trong phát triển
- Thay vì chạy theo độ phổ biến, bài viết đề cao niềm vui tạo ra sản phẩm và tính sáng tạo, và khép lại với thông điệp “hãy thử lại Rails thêm một lần nữa”
4 bình luận
Nếu là Rails thì tôi nhớ là "quy ước hơn cấu hình" chứ không phải "cấu hình hơn quy ước"...
> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails đã loại bỏ tất cả những thứ đó và đưa ra khái niệm “convention over configuration”
Có vẻ như LLM đã xuất ra đúng theo thứ tự đầu vào mà không thay đổi trật tự từ. Trong nguyên văn thì đã được viết đúng.
LLM cũng nhầm mấy chỗ như thế này nhỉ. Tôi đã sửa lại rồi. Cảm ơn bạn.
Ý kiến Hacker News
Tôi rất thích Rails, nhưng sau khi từng làm việc với codebase lớn không có kiểu tĩnh, tôi thấy rất khó quay lại Rails ngoài các dự án cá nhân
Các codebase lớn không có kiểu tĩnh là cơn ác mộng để bảo trì, ngay cả khi có IDE mạnh như RubyMine
Tôi tò mò không biết Sorbet hiện đã tiến bộ đến mức nào, đặc biệt là độ ăn ý với RoR
Nó theo rất sát triết lý của Rails, đồng thời giúp việc học Rust trở nên dễ dàng hơn
Rất đáng để thử vào cuối tuần
Bạn phải sao chép dữ liệu production thực tế về máy local hoặc SSH vào server rồi dùng REPL để kiểm tra trạng thái
Debug trong IDE là một trải nghiệm địa ngục
Tôi thật sự rất yêu Ruby, nhưng sau khi trải qua việc debug thời gian thực thì thấy quá khó khăn
Giờ không còn lý do gì để cố chọn Ruby hay Python nữa
Python có thể còn trụ lại thêm một thời gian trong ML, nhưng cuối cùng tôi nghĩ nó cũng sẽ biến mất
Tôi cũng vui vì có người nói công khai điều này
Dạo này tôi đã mệt mỏi với kiến trúc microservices quá mức
Buổi tối tôi thích làm những dự án chỉ đơn giản giải quyết vấn đề mà không có cấu trúc thừa thãi
Trước đây tôi từng xử lý nhiều cấu trúc PHP, nhưng dù là Rails hay PHP thì cuối cùng cũng chỉ là công cụ giải quyết vấn đề
Nó giống cảm giác phát triển bằng IDE desktop ngày xưa, khi mọi thứ đều chạy “trong một chiếc hộp”
Tôi có cảm giác như đang lấy lại được sự đơn giản lấy năng suất làm trung tâm, thay vì phải quản lý các thành phần phức tạp của phát triển web
Hơn nữa còn không phải dùng TypeScript nên quá tuyệt. Tôi thấy TypeScript dài dòng và đầy boilerplate không cần thiết
Chúng tôi vẫn đang vận hành ứng dụng Rails trên production liên tục từ năm 2007
Bí quyết sống lâu của Rails không nằm ở tuổi tác, mà ở sự ổn định và tính thực dụng của nó
Khẳng định rằng dùng JavaScript ở backend sẽ hiệu quả hơn đã bị bác bỏ từ lâu
Phần lớn thay đổi về stack công nghệ đến từ tối ưu hồ sơ xin việc hoặc nỗi lo bị bỏ lại bởi xu hướng, chứ không phải từ nhu cầu kỹ thuật thực tế
Rails vẫn lặng lẽ tiếp tục vận hành các doanh nghiệp thật
Chẳng ai thực sự nghĩ rằng 3,1 triệu package của NPM cung cấp nhiều chức năng hơn 190 nghìn package của RubyGems
Hiện đang migrate sang Inertia + Vue.js, và đây là một tổ hợp mạnh đến mức gần như không cần thay đổi gì ở backend
Mức tăng năng suất còn bù được cả độ khó trong tuyển dụng
Càng nhiều người dùng thì hệ sinh thái càng khỏe mạnh
Nhưng RubyGems cũng có nhiều package cũ, nên tôi nghĩ rất khó so sánh đơn giản như vậy
Tôi thích triết lý “kèm pin sẵn” của RoR hay Django, nhưng việc bảo trì các dự án cũ rất tốn thời gian
Muốn cập nhật một dự án đã 5~6 năm tuổi thì quản lý dependency là gánh nặng lớn
Vì thế dạo này tôi thích dùng framework đơn giản của Go hoặc thậm chí là không dùng framework
Chỉ dùng những thư viện thật sự cần thiết thì việc bảo trì sẽ dễ dàng
Ngoài vá bảo mật ra thì tôi cũng tự hỏi có lý do gì buộc phải cập nhật không
Trong một năm rưỡi qua tôi đã nâng 5 phiên bản major mà vẫn tương đối đơn giản
Nếu cấu hình cẩn thận ngay từ đầu thì về lâu dài gần như không phải đụng vào nhiều
Tôi nghĩ trải nghiệm nâng cấp đang bị đánh giá thấp
Next.js thay đổi hoàn toàn cấu trúc ở mỗi phiên bản major, còn Rails thì chu kỳ loại bỏ dần (deprecation) chậm hơn nên ổn định hơn nhiều
Khi bạn phải liên tục triển khai sản phẩm, độ ổn định của giao diện quan trọng hơn rất nhiều so với việc chạy theo paradigm mới nhất
Việc chuyển từ pages sang app router của Next.js trên thực tế gần như là một cuộc tái nền tảng hóa toàn bộ
Trong khi đó Rails có lộ trình nâng cấp được tài liệu hóa rõ ràng và chu kỳ deprecation dễ đoán
Việc quản lý phiên bản Ruby nhờ rbenv/asdf cũng gần như loại bỏ vấn đề lệch môi trường
Tôi đã làm mọi thứ với Rails hơn 10 năm, từ DevOps đến web developer một người, và nếu làm lại tôi vẫn sẽ chọn như vậy
Rails là một framework gọn gàng và hiệu quả có đủ mọi thứ
Trong khảo sát của Stack Overflow, nó vẫn nằm trong “Top 5 stack muốn dùng cho dự án tiếp theo”
Gần như không cần phải lo cả phần cấu hình hạ tầng, và triển khai cũng đơn giản
Cuối cùng điều quan trọng không phải ánh nhìn của người khác, mà là dùng công cụ phù hợp với chính mình
Nó ra đời sớm hơn Django 1 năm
Liên kết khảo sát
Trước đây tôi từng nghĩ Ruby/Rails là lời giải tối ưu cho hầu hết mọi vấn đề, và đến giờ tôi vẫn nghĩ vậy
Tôi chưa dùng Rails, nhưng tôi đồng cảm với sự hỗn loạn của môi trường phát triển web hiện nay
Vì thế tôi đã nhìn về tương lai và chọn Elixir và Phoenix
Tôi nhất định sẽ thử ở dự án tiếp theo
Tôi tò mò điều gì ở Elixir lại hấp dẫn đến vậy, và khi mới tiếp cận thì nên chú ý điểm nào
Mười năm trước tôi từng xây dựng frontend streaming cho một đài truyền hình lớn ở Thụy Điển bằng Rails
Trên Heroku, nó xử lý hơn 1 triệu người dùng đồng thời và hoạt động rất tốt
Sau đó tôi chuyển sang các lĩnh vực khác như hạ tầng streaming, API, AI/ML, nhưng không phải vì Rails thất bại mà vì bản chất của vấn đề đã thay đổi
Rails phù hợp với các bài toán xoay quanh data model và business logic, còn với các bài toán thiên về đồng thời hay hạ tầng thì những ngôn ngữ khác phù hợp hơn
Ruby vẫn là một ngôn ngữ đẹp và giàu khả năng biểu đạt, và tôi rất nhớ nó
Nhưng tôi cảm thấy rất khó để hoàn toàn gạt bỏ thiên kiến cá nhân với ngôn ngữ mình yêu thích
Tôi tò mò không biết bạn đã làm dự án tiếp theo bằng ngôn ngữ nào
Với những người tiếc vì thiếu kiểu tĩnh, đã có những giải pháp tuyệt vời như Sorbet
Bạn có thể vừa tận hưởng năng suất của Ruby, vừa có kiểu tĩnh và tích hợp LSP
Nhờ Shopify mà Sorbet cũng được hỗ trợ tốt trong Rails
Tôi yêu hệ sinh thái này đến mức vẫn muốn tiếp tục làm việc với Rails
Nhờ sự phát triển của các công cụ AI, giờ tôi nghĩ giới hạn duy nhất chỉ còn là trí tưởng tượng
Tôi đã xây dựng một agent thương mại điện tử dựa trên nó để giám sát cửa hàng 24/7 và gửi cảnh báo qua Slack
Nếu bạn làm dự án liên quan đến AI, rất đáng để xem selzee.com/openclaw