Rails cho mọi thứ - Sức mạnh của Rails cho mọi thứ

• Rails 8 rất hữu ích cho các dự án nhỏ và nhà phát triển một người
• Có thể xây dựng ứng dụng ở mức production một cách dễ dàng với hướng dẫn bắt đầu mới nhất
• Nhờ cải tiến của SQLite, có thể tạo ra môi trường cơ sở dữ liệu mạnh mà không cần máy chủ bổ sung
• Với CI và trình tạo xác thực tích hợp sẵn, hiệu quả phát triển và bảo mật được nâng cao
• Với cách triển khai đơn giản qua Kamal, có thể vận hành dịch vụ nhanh chóng và an toàn

---

Tổng quan

• Dựa trên kinh nghiệm sử dụng Rails 8, đây là khung web xuất sắc cho các dự án nhỏ hoặc nhà phát triển cá nhân
• Nhờ xây dựng nhanh, triển khai hiệu quả và mô-đun tích hợp sẵn, lợi thế về năng suất so với các framework cạnh tranh là nổi bật

Ưu điểm của hướng dẫn mới nhất

• Hướng dẫn mới Getting Started with Rails được thiết kế để người mới bắt đầu cũng có thể tạo ra một ứng dụng production
• Quá trình cài đặt Ruby vẫn còn phức tạp, nhưng nếu theo hướng dẫn, có thể xây dựng một dịch vụ vững chắc với đủ xác thực, caching, rich text, tích hợp liên tục (CI), cơ sở dữ liệu
• Điểm mạnh không phải là một ví dụ ‘Hello World’ đơn thuần, mà là việc cung cấp nền tảng và các tính năng ở mức độ dịch vụ thực tế
• Với người mới chưa quen với Rails, đây là điểm khởi đầu tối ưu

Chỉ cần SQLite là đủ

• SQLite vốn là công cụ tuyệt vời, nhưng trước đây nó khó cấu hình để dùng cho môi trường production
• Trước kia cần cài đặt thêm các gem, nhưng ở Rails 8, nó có thể được sử dụng ổn định trong production mà không cần công việc bổ sung nào
• Không cần chạy PostgreSQL hay khởi động server riêng, và khi dùng solid cache thì không cần server redis
• Dịch vụ có thể vận hành chỉ với Rails và SQLite, tối đa hóa độ đơn giản khi xây dựng và vận hành cũng như hiệu quả chi phí

Tích hợp liên tục (CI) dễ dàng

• Ngay sau commit đầu tiên, thông báo lỗi tích hợp liên tục (CI) đã có thể đến, cho thấy Rails 8 đã cung cấp sẵn cấu hình CI tích hợp
• Nó tự động tích hợp với GitHub Actions mà không cần thêm công việc và cung cấp 2.000 phút chạy miễn phí mỗi tháng
• Đối với nhà phát triển một người, đây là quỹ thời gian khá dồi dào

Giới thiệu trình tạo xác thực

• Các gem xác thực như Devise trước đây dù mạnh nhưng thường khiến người mới cảm thấy khó do độ phức tạp trong cấu hình
• Rails 8 bổ sung trình tạo xác thực đơn giản, chỉ cần thêm người dùng hiện có từ console là có thể hiện thực hóa luồng đăng nhập một cách dễ dàng
• Mã được tạo ra đơn giản và dễ đọc, nên người mới cũng dễ hiểu

Triển khai nhanh chóng và dễ dàng với Kamal

• Kamal chịu trách nhiệm toàn bộ quy trình triển khai; chỉ cần chỉnh sửa một phần nhỏ file deploy.yml và làm theo hướng dẫn là có thể chạy ứng dụng ngay trong môi trường SSL
• Đây là trải nghiệm triển khai web app nhanh hơn so với việc kết nối SSL cho GitHub Pages
• Sự kết hợp giữa CI tích hợp liên tục và triển khai dễ dàng là điểm rất nổi bật của Rails 8
• Chỉ cần làm theo hướng dẫn khởi đầu, vẫn có thể có trải nghiệm phát triển phù hợp với best practice mới nhất

Kết luận

• Rails vẫn là một framework mạnh mẽ và đang tiếp tục phát triển
• Nếu năm nay bạn đang cân nhắc một dự án mới, việc thử phát triển với Rails 8 là điều đáng làm

[aer0700]

Dạo gần đây thấy rất nhiều bài viết về SQLite, giờ thì hóa ra SQLite đã đi đến mức mọi thứ đều dùng SQLite rồi.
Phải gọi đây là sự hồi sinh của thứ đã trở thành kinh điển không?

[GN⁺]

Ý kiến Hacker News

• Gần đây mình làm app bằng stack Spring Boot, Micronaut và cả frontend React. Cách tiếp cận omakase (tức là có sẵn mọi thứ cần thiết) của Rails khiến mình thấy rất dễ chịu. Ngay cả các chức năng đơn giản từ backend như kiểm tra tính hợp lệ form hay flash message cũng không được framework giải quyết trực tiếp, nên mình phải tự viết hoặc tìm bên thứ ba. Rails đã giải quyết trước cho khoảng 90% vấn đề mà web app thường gặp. Không thể nói là hoàn hảo, nhưng trong hầu hết trường hợp chỉ dùng phần tích hợp sẵn là đủ và khi cần có thể thay thế bất cứ lúc nào
  • Spring Boot gần như có sẵn kiểm tra tính hợp lệ form và kích hoạt ngay bằng annotation
• Mình nghĩ Rails và Django đều là những framework tuyệt vời. Mình từng viết cả app mission-critical bằng Python. Nhưng khi phát triển monolith lớn thì mình có xu hướng chuyển sang Go vì cảm giác hệ thống kiểu Go có type system và concurrency mạnh hơn. Vấn đề là hệ sinh thái Go chưa tạo ra được ecosystem framework kiểu Rails hay Django. Với Go thì giỏi nhất cho công cụ networking hay CLI, nhưng khi cần xây nhanh web app fullstack thì mình vẫn chọn Rails hoặc Django. Vì vậy mình không tin câu “Rails đã chết”.
  • Nhờ các công cụ như ogen, chỉ với một tài liệu OpenAPI có thể tự động sinh gần như toàn bộ các tính năng như router tĩnh, validate request/response, theo dõi Prometheus, tracing OpenTelemetry... tạo code webhook cho client cũng được, còn auth chỉ cần thêm một chức năng. Kết hợp sqlc với pragma user_version của SQLite thì mã DB type-safe và migration cũng dễ hơn. Chỉ cần import hai dòng trong main.go để thêm SQLite. Với template chuẩn của Go đã đủ cho xử lý text frontend, và nhờ embed mà asset tĩnh cũng đưa vào binary rất dễ. Việc deploy trực tiếp cũng chỉ cần go build rồi di chuyển binary, nên deploy trở nên rất đơn giản. Các công cụ sinh code đã làm backend Go nhanh và dễ hơn rất nhiều.
  • Mình cũng từng muốn một stack static typing hoàn chỉnh, nhưng rõ ràng ASP.NET là lựa chọn đúng hơn Go hay Rust. Dù Microsoft đang đẩy mạnh các sản phẩm mới (ví dụ: Aspire.NET), song chính .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) mới là bản chất “batteries included” và đáng tin cậy hơn. Có chút đổi hướng tư duy OOP và DI nhưng với dev có kinh nghiệm thì không thành vấn đề lớn.
  • Vấn đề của hệ sinh thái Go không chỉ là tư duy chống framework mà còn là tư duy chống tính năng hiện đại. Java, Kotlin, Scala, C#, F#... cũng đều tốt cho phát triển networking tool hoặc CLI. Dạo này Java AOT cũng không còn lo lắng về bản quyền thương mại, và .NET cũng không còn bị khóa vào Windows.
  • Mình muốn giới thiệu Encore. Đặc biệt, khi tích hợp PaaS (như combo NextJS+Vercel) thì nó rất mạnh. Dù hơi khác với nguyên tắc cốt lõi của Go, Encore là lựa chọn rất tốt cho nhóm nhỏ hoặc solo team. Nếu cần, có thể deploy trực tiếp bằng BYOC hoặc tự dựng API layer bằng stdlib mà không vấn đề gì. Frontend vẫn nên là NextJS hoặc Remix/RR7, và nhờ sinh tự động TypeScript client SDK nên tích hợp cực dễ. Encore có tích hợp PR với Vercel nên đây cũng là điểm mạnh lớn.
  • Để có cảm giác gần như Django trên Go thì beego là một trong số ít chọn khá ổn. Nhưng vẫn còn thiếu độ mature, nên chưa thể gọi là tầm Rails/Django.
  • Dự án hiện tại của mình làm bằng Go khiến mình rất hài lòng với code sạch. AI giúp đỡ rất nhiều trong việc vượt qua rào cản vào framework. Dẫu vậy, với dịch vụ hướng khách hàng thì vẫn là Rails, còn công cụ nội bộ/xử lý dữ liệu thì Django trực quan hơn.
  • Ruby dùng Sorbet cũng có thể type-check, và feature concurrency qua Fiber gần như đã đến giai đoạn hoàn thiện. Có một web server mới tên Falcon đang được xây bằng Fiber. Chưa bằng Puma, nhưng sẽ sớm dùng production ổn.
  • Tác giả ngôn ngữ Stanza viết một bài về nhận định rằng để có framework mạnh như Rails, bản thân ngôn ngữ phải có những điều kiện nhất định. Việc Go hay Java thiếu framework kiểu đó là kết quả phối hợp giữa giới hạn của ngôn ngữ (hoặc của programmer).
  • Go về bản chất không hướng tới framework fullstack kiểu (Rails/Django).
  • Node/Express phù hợp mức pico-service cho dev local, còn ASP.NET WebAPI/MVC lại là backend lý tưởng của mình.
  • goravel dev cũng đáng để thử một lần.
• Nếu đi từ đầu đến cuối theo Rails Guides, bạn có thể tung ngay một dịch vụ thật với auth, caching, rich text, CI, DB. Nhưng dù thích hợp cho GitHub, Airbnb quy mô lớn, trong startup ban đầu thì việc đưa ngay toàn bộ tính năng thêm/sẵn có như Devise, turbo, testing từ đầu có thể lại tốn thời gian. Turbo có ưu điểm load trang nhanh hơn, nhưng đôi khi xung đột với chức năng của Devise và khiến thời gian dev tăng. Khi chưa public và đang giai đoạn validate idea, trừ banking/medical app thì có thể hoãn test hay CI cũng không vấn đề lớn. Quan trọng là đừng sa đà vào định kiến mặc định (dùng vì có sẵn), hãy tự tin nói “mình chưa dùng cái này bây giờ”.
  • Nếu định làm SaaS app, bắt đầu với template Rails chuyên biệt như Jumpstart Pro hay Bullet Train sẽ cắt giảm được vài tháng dev. Chúng đã tích hợp sẵn chức năng cơ bản như payment, auth và mở rộng sau này khá dễ.
  • Mình không đồng ý với luận điểm về testing. Ngay cả app nhỏ, nếu có test code thì thực ra tiết kiệm thời gian hơn. CI thường chỉ cần một file khoảng hai chục dòng, và mình từng copy/paste từ dự án trước.
  • CI là yếu tố rút ngắn tốc độ phát triển. Nên thêm CI ngay giai đoạn đầu dự án.
  • Mình muốn biết lúc nào là thời điểm chuyển từ Flask/Express/Sinatra/Gradio/Hono sang Rails.
• Rails mới giờ trông rất mượt và đẹp mắt hơn trước, nhìn rất vui. Từ Rails 2.3 đến nay đã 12 năm mình maintain nhiều app, giờ Rails giống một Pokémon tiến hóa khác hẳn. Rails Upgrade Guide được viết cực kỳ rõ nên mình có thể nâng cấp mượt mà mà không cần refactor lớn. Không phải luôn backwards compatible, nhưng lợi thế là mọi thay đổi đều được tài liệu hóa rõ ràng. Với ActiveStorage, xử lý đính kèm file đã tiến bộ đáng kể; việc chuyển qua Webpacker có hơi tốn công nhưng giờ với Import Maps thì dễ hơn. Mình dự định nâng cấp lên 8.1 trong năm nay.
  • 4 năm trước mình chấp nhận cắt lương để bảo trì app Rails cũ cho khách hàng ngân sách thấp (hồi Ruby 2.3). Kết quả là nâng cấp và thêm tính năng thật sự rất dễ, nên rất hài lòng.
• Mình phát triển một project Rails open source một mình và hỗ trợ 120k người dùng/tháng, nên rất đồng tình với ý kiến trên. Ngoài ra, tính năng đính kèm file của ActiveStorage thật tuyệt vời. Mình hay deploy bằng Dokku, nhưng rất mong chờ thử Kamal. Rails đang liên tục tiến hóa, và Ruby ngày càng nhanh hơn.
  • Nếu bạn thích Dokku, đã thử chưa Cloud Native Buildpacks? Cái này có thể tạo luôn image OCI.
• Học Ruby thì tỉ lệ web dev không lớn với mình, nên thường chỉ biết Django. Mình tò mò hai framework này khác nhau ở đâu.
  • Mình đã có kinh nghiệm lâu với cả hai hệ sinh thái (gần đây làm Rails ít hơn). Django gắn với Python, Rails gắn với Ruby/gem nên ảnh hưởng lớn từ ecosystem. Django admin CMS chắc chắn mạnh hơn Rails; nhiều tổ chức làm toàn bộ CMS nội bộ bằng Django. Rails có CLI scaffolding khủng nên tạo CRUD cực nhanh. Rails có mức trừu tượng hóa cao hơn và gần như tự động xác định cấu trúc, kiến trúc, nên Django cho phép dev tự chọn nhiều hơn. Với DRY và chống duplicate code, Rails bám chặt hơn. Người thiên về trực giác pythonic có thể thấy “magic” của Rails nặng, còn phía Rails thì có thể thấy Python lặp đi lặp lại khá thô. Cốt lõi là hai bên khác style.
  • Nếu mình làm web app (consumer facing product), mình sẽ chọn Rails trước. Cảm giác build scaffolding và đưa sản phẩm ra thị trường dễ hơn (mình chưa có kinh nghiệm dịch vụ rất lớn). Với công cụ nội bộ, data work hay GIS thì Python/Django tốt hơn.
  • Sự khác biệt lớn nhất là Python vs Ruby. Ecosystem Python quá lớn và Django có auth cùng admin tích hợp.
  • Trong môi trường test, mình thấy Rails tốt hơn. Rails có sẵn cấu hình CI và tự sinh test code.
  • Theo kinh nghiệm, Django Admin dễ linh hoạt và dễ dùng hơn giải pháp thay thế phía Ruby. Ngược lại, testing và routing của Rails thì tốt hơn và convention cũng chặt hơn. Mình thích ActiveRecord+arel hơn Django ORM. (Cá nhân thì viết Ruby thấy thú vị hơn Python.)
  • Ruby không khó học, và Rails cung cấp nhiều cấu trúc và convention sẵn hơn Django rất nhiều.
• Nhiều người có cảm giác gần như mức độ gắn bó kiểu tình yêu với Rails, còn mình thì không cảm được đến mức đó nên có lúc thèm muốn vậy đó. Dù framework nào cũng có fan, nhưng nhiệt tình với Rails có vẻ đặc biệt hơn.
  • Dù có khá nhiều chỗ mình thấy khó chịu khi tiếp xúc với convention của Rails, nhưng thử đạt productivity tương tự với backend JavaScript gần như là điều không thể. Mặt khác, khi giữ code Rails, mình đã thấy nhiều case tự implement lại feature built-in của Rails (ví dụ Active Job) mà không rõ lý do. Tuân theo convention thường hiệu quả hơn.
• Khi thử SQLite production thì chuyện migration vẫn làm mình đụng phải đúng cuối cùng. Ví dụ, muốn thêm ràng buộc NOT NULL cho cột có sẵn thì phải rewrite toàn bộ bảng qua bảng tạm.
  • SQLite không có ADD CONSTRAINT và không hỗ trợ ngôn ngữ PL hay stored proc đơn giản, nên thường xuyên phải roundtrip về host language, với ngôn ngữ statically typed thì càng phiền.
  • Mình nghĩ Postgres là tốt nhất nên khó bỏ qua. Dù vậy việc Rails đưa sqlite3 vào như lựa chọn first class là một tiến triển tích cực.
  • Khuyến nghị mặc định của Rails rằng SQLite là thay thế Redis cũng có, nhưng thực tế chỉ phù hợp cho việc bắt đầu các service nhỏ. Nếu sau này sẽ chuyển DB khác thì mình không khuyên start với SQLite, vì migration luôn đau đớn.
  • Với Rails, phần lớn việc này có thể quản lý bằng ActiveRecord validation, nhưng có hạn chế trong việc phản ánh các ràng buộc nền tảng.
• Hướng dẫn cài Ruby hơi rắc rối. Lần đầu thiết lập blog jekyll sau 15 năm, mình gặp khó khăn với gem... Dù một phần do lỗi của mình, nhưng vẫn thấy nếu nó dễ xử lý hơn thì tốt. Dẫu sao nó vẫn khiến mình muốn thử Ruby lần nữa.
  • Setup phải dễ cho ai cũng. Mình học nhanh Jekyll vì máy đã có sẵn Ruby và RubyGems.
• Nếu chỉ dùng SQLite, litestack cũng đáng xem qua một lần. Mình chưa dùng trực tiếp nhưng dự định đổi dự án cá nhân từ postgres sang litestack. Benchmark performance cực ấn tượng.
  • Rails 8 đã tăng cường SQLite đáng kể, nên bây giờ không biết có cần đến litestack không. Mình muốn biết nó có điểm khác biệt gì