Vì sao tôi chọn Elixir Phoenix thay vì Rails, Laravel, Next.js

 (akarshc.com)
7 điểm bởi GN⁺ 2025-10-18 | 3 bình luận | Chia sẻ qua WhatsApp
  • Phoenix LiveView mang lại hiệu quả cao cả về tốc độ ứng dụng lẫn tốc độ phát triển
  • Ưu điểm là có thể xử lý theo kiểu monolith bằng một ngôn ngữ duy nhất, không cần duy trì riêng frontend và backend
  • Đã cân nhắc Rails Hotwire và Laravel Livewire, nhưng việc triển khai tính thời gian thực và tác vụ nền đòi hỏi nhiều cấu hình hơn
  • Framework Phoenix của Elixir giữ được sự thanh lịch của Ruby on Rails nhưng mang lại hiệu năng vượt trội hơn nhiều, có tác vụ nền thông qua Oban được tích hợp sẵn, và hỗ trợ cú pháp quen thuộc, gọn gàng
  • LiveView cung cấp cập nhật hai chiều theo thời gian thực dựa trên WebSocket, tạo sự cân bằng giữa server rendering truyền thống và các framework thiên về frontend, đồng thời có thể dùng Alpine.js hoặc thư viện JavaScript thông qua hooks khi cần
  • Tốc độ phát triển nhanh, khả năng xử lý đồng thời cao, có thể viết hầu hết mọi thứ bằng một ngôn ngữ duy nhất, ngăn lỗi sớm nhờ compiler, và kiến trúc chịu lỗi trên nền Elixir/Erlang là những yếu tố quyết định cuối cùng

Vì sao chọn Phoenix LiveView

  • Mục đích của việc lập trình là giải quyết vấn đề theo cách tối ưu nhất, và yếu tố quan trọng nhất với tôi là tốc độ ứng dụng và hiệu quả phát triển
  • Nếu dùng React hoặc Next.js cùng với Laravel, hay dùng Inertia.js với Laravel, bạn phải duy trì toàn bộ cả frontend lẫn backend stack
  • Là một solo developer, tôi không có thời gian để quản lý trạng thái ở hai nơi khác nhau, và tôi cần một giải pháp monolith vững chắc có thể xử lý mọi thứ cùng nhau

  • So sánh các lựa chọn: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire và Rails Hotwire là những công cụ tuyệt vời giúp đơn giản hóa công việc frontend mà không phụ thuộc quá nhiều vào JavaScript
    • Tôi cũng cân nhắc một stack JavaScript hoàn toàn với Next.js, nhưng không thích dùng JavaScript ở backend
    • Rails Hotwire đặc biệt thu hút nhờ khả năng xây MVP nhanh bằng Rails
    • Tuy nhiên, tôi cần tác vụ nền, cập nhật thời gian thực và giao tiếp hai chiều; những thứ này vẫn làm được với Rails và Laravel nhưng cần nhiều công sức cấu hình hơn

  • Những ưu điểm quyết định của Elixir, Phoenix và LiveView

    • Elixir và Phoenix giữ được sự thanh lịch của Ruby on Rails đồng thời mang lại hiệu năng cao hơn rất nhiều
    • Background job tích hợp qua Oban, cú pháp quen thuộc, dễ đọc, cùng với khả năng giao tiếp hai chiều theo thời gian thực của LiveView là những điểm mạnh nổi bật
    • LiveView tạo ra sự cân bằng lý tưởng giữa cách tiếp cận server rendering và các framework nặng về frontend
    • Có thể cập nhật theo thời gian thực qua WebSocket và tích hợp các thư viện JavaScript (ví dụ: Alpine.js)
    • Phoenix tích hợp Oban nên việc khai báo background job và tự động khôi phục trở nên dễ dàng

  • Lợi ích của Elixir/Erlang

    • Elixir là ngôn ngữ biên dịch được xây dựng trên Erlang, nền tảng đứng sau các hệ thống đồng thời quy mô lớn như WhatsApp và Discord
    • Cung cấp độ đồng thời cao, khả năng chịu lỗi và tự động khôi phục khi sự cố xảy ra

Lý do cho lựa chọn cuối cùng

  • Phát triển nhanh và hỗ trợ đồng thời cao
  • Có thể triển khai gần như mọi thứ bằng một ngôn ngữ duy nhất
  • Viết được mã nguồn dễ đọc
  • Compiler bắt được phần lớn lỗi trước khi chúng lên production
  • Kiến trúc chịu lỗi giúp ứng dụng gần như không bị sập, đảm bảo độ ổn định của ứng dụng

Kết luận và lời khuyên

  • Phoenix không mặc định vượt trội hơn Rails, Laravel hay Next.js trong mọi trường hợp
  • Mọi framework đều rất tốt, và tác giả đều đã có kinh nghiệm dùng chúng cho nhiều dự án khác nhau
  • Với hoàn cảnh cụ thể và dự án (Hyperzoned.com) của mình, Phoenix là lựa chọn phù hợp nhất
  • Nếu dám khám phá vượt ra ngoài những gì mình đã biết, bạn có thể tìm ra cách tốt hơn và hiệu quả hơn để giải quyết vấn đề tiếp theo
  • Đừng ngừng học hỏi

Bài viết liên quan

3 bình luận

 
clastneo 2025-10-23

Cũng giống như JSP, khi vượt quá một mức độ nhất định thì tôi cảm thấy không thể tiếp tục dùng được nữa.
 
GN⁺ 2025-10-18
Ý kiến trên Hacker News

  • Tôi đã trực tiếp tích hợp CKEditor cho Rails, Livewire, Phoenix và React. Trong số đó, về trải nghiệm lập trình viên thì Phoenix là ấn tượng nhất. Framework được thiết kế rất tốt nên việc tích hợp thực sự rất đơn giản. Với Rails và React, đặc biệt là Next.js, tôi hoàn toàn không có được cảm giác hài lòng như vậy. Next.js thay đổi router quá thường xuyên, lần nào cũng khác nên khó mà tin cậy được. Livewire có cảm giác khá giống Phoenix nhưng tương đối kém trực quan hơn và thiếu tính năng hơn. Ví dụ, Livewire không hỗ trợ component slot, còn Phoenix thì xử lý ngon lành. Không có slot thì cấu trúc template trở nên lộn xộn và mã cũng phức tạp không cần thiết. Ai tò mò có thể xem github ckeditor5-phoenix

    • Kết hợp PHP(Laravel) với JQuery đến năm 2025 vẫn còn dùng ổn. Tuy nhiên cá nhân tôi không muốn dùng Livewire. Node.js có thể kém năng suất hơn, nhưng hữu ích khi cần các khả năng mạnh hơn. Nó hỗ trợ async/await, socket.io, TypeScript. Next.js đúng là hữu ích khi vừa cần SEO vừa cần UI tương tác, nhưng thực tế có bao nhiêu website thật sự cần tất cả những thứ đó cùng lúc? Có lẽ chỉ các dịch vụ như LinkedIn mới thuộc kiểu này

    • Tôi không nghĩ Livewire là bản sao của Phoenix. Nhìn tên thì có vẻ vậy, nhưng theo tôi biết thì hai dự án gần như bắt đầu cùng lúc và Livewire thậm chí còn lâu đời hơn. Hotwire là cái ra muộn nhất. Hai dự án đi theo các cách tiếp cận khác nhau, mà PHP và Elixir thì khác nhau quá nhiều về đặc tính. Tôi cũng thấy Livewire khá hữu ích. Vì không thể dễ dàng dùng WebSocket trong PHP nên nó chủ yếu hoạt động trên HTTP, và trong đa số trường hợp như vậy là đủ. Ngược lại, WebSocket của LiveView đôi khi còn là quá mức cần thiết

    • Tôi tò mò cụ thể về trải nghiệm vấn đề với Rails. Muốn nghe xem phần nào là khó khăn

    • Tôi muốn biết dùng Rails thì điểm nào là khó

    • Livewire 4 dự kiến sẽ hỗ trợ component slot. Nhưng vẫn còn vài tuần nữa. Bản mới cũng được nói là sẽ cải thiện hiệu năng và độ tiện lợi khi phát triển

  • Bài này có vẻ là kiểu tác giả bênh vực framework mình đã chọn và cố tình lờ đi các tính năng của framework khác. Những điểm được nêu là ưu thế của Phoenix thì Rails cũng đều có. Ngoài ra, nó còn tạo cảm giác như Rails không hỗ trợ giao tiếp frontend và WebSocket, nhưng với ai đã làm app bằng Rails trong 3 năm gần đây thì đó là nhận định hoàn toàn sai. Dĩ nhiên Phoenix và LiveView cũng là công cụ tốt, nhưng lý do tôi vẫn tiếp tục dùng Rails là nhờ Hotwire Native. Nó cho phép một mình tôi làm cả ứng dụng mobile lẫn web trong thời gian ngắn, đây là lợi thế cực lớn về năng suất

    • Tôi không dùng Ruby nhiều, nhưng ngoài cộng đồng thì tôi tò mò Ruby on Rails vượt Elixir & Phoenix ở điểm nào. Nhờ nền tảng BEAM mà Phoenix về lý thuyết vượt trội hơn hẳn với hệ thống soft real-time, khả năng chịu lỗi, NIFs, actor model, vô số process nhẹ, concurrency dễ suy nghĩ, lập trình hàm, OTP, GC không ngắt quãng. Tất nhiên cứ dùng thứ mình thích là được, và tôi cũng định thử Hotwire Native một lần

    • Việc Rails có thể giao tiếp với frontend qua WebSocket là điều rõ ràng. Thực tế tôi là lập trình viên Rails, nhưng nếu cần lượng lớn kết nối socket duy trì liên tục thì tôi sẽ chọn Phoenix. Với các dịch vụ như Gigalixir, Phoenix có thể gánh 100.000 kết nối socket rẻ hơn và dễ hơn nhiều. Nếu tự quản lý hạ tầng thì lại là chuyện khác. Nhưng với Heroku thì ngay cả vài nghìn kết nối cũng đã khó và chi phí cũng nặng

    • Tôi tò mò đoạn nào trong bài nói Rails không hỗ trợ giao tiếp WebSocket với frontend. Trong nguyên văn chỉ nói là “việc này Rails và Laravel đều làm được nhưng tốn thêm một chút thời gian để thiết lập”. Đây là sắc thái hoàn toàn khác

    • Tổ hợp Rails + Hotwire cũng cực kỳ mạnh, thêm Hotwire Native thì còn tốt hơn. Điểm chính của bài này không phải là Phoenix và LiveView tốt hơn, mà là cấu trúc của LiveView (trạng thái do server điều khiển, tách process, channel nhẹ, v.v.) phù hợp với một số tình huống nhất định. Cả hai hệ sinh thái đều đang giải quyết các bài toán tương tự theo những cách khác nhau. Rails tiếp cận bằng convention và progressive enhancement, còn Phoenix bằng concurrency và khả năng chịu lỗi của BEAM. Cuối cùng điều quan trọng là cấu trúc nào hợp với sản phẩm mình đang xây dựng hơn

    • Tôi đã từng nghe về Hotwire Native, nhưng sau đó có vẻ ít thấy tin tức. Tôi tò mò về trải nghiệm dùng nó cho app mobile thật, về hỗ trợ hay tài liệu, và mức độ hoàn thiện khi triển khai

  • Tôi cũng có cảm tình tích cực với Elixir không kém tác giả, nhưng với tư cách CTO, sau 3 năm dùng trong production thì càng lên quy mô lớn tôi càng thấy tiếc nuối. BEAM (concurrency, khả năng chịu lỗi) đã giữ đúng lời hứa, và Ecto, Oban, remote iex, nguồn nhân lực đều rất tốt. Nhưng trải nghiệm lập trình viên (DX) dần trở thành nút thắt cổ chai. Trong một dự án lớn 300.000 dòng mã, có các vấn đề như sau:

    • Thời gian biên dịch: chỉ thay đổi một dòng mã thôi mà môi trường dev đã mất hơn 10 giây để compile, liên tục làm đứt mạch tập trung
    • Tooling: tính năng tự động hoàn thành của ElixirLS không đáng tin cậy, nên mất thời gian tìm tên hàm hoặc field của schema
    • LiveView: không phù hợp với UI phức tạp nên cuối cùng vẫn phải đưa frontend React vào, và thế là độ phức tạp của GraphQL cùng việc tách stack lại quay trở về y nguyên
      Nếu đang cân nhắc một stack dùng dài hạn thì đọc retrospective 3 năm sẽ hữu ích

    • Việc compile trong môi trường dev của Elixir mất hơn 10 giây cho một lần là điều khiến tôi rất ngạc nhiên. Tôi luôn chỉ nghe rằng Elixir có nhiều lợi thế hơn Rails, nên tôi tò mò không biết những trường hợp như vậy có phổ biến ngoài thực tế không

    • Tôi cũng có trải nghiệm tương tự khi học Elixir. Tôi thích ngôn ngữ này, nhưng khi làm việc trên Windows qua WSL thì LSP hay bị lỗi nên rất bất tiện. LSP chính thức sắp ra mắt nên tôi hy vọng phần này sẽ được cải thiện mạnh

    • Nếu frontend như LiveView hay React không được quản lý tốt thì trong ứng dụng lớn mã sẽ nhanh chóng trở nên lộn xộn. Càng đông người thì càng bắt buộc phải code review và dọn dẹp logic dư thừa. Có vẻ phần này framework nào cũng vậy. Vẫn còn rất nhiều chỗ để cải thiện trong tương lai

  • Bài viết khẳng định rằng “các tác vụ nền, cập nhật thời gian thực và giao tiếp hai chiều nhẹ nhàng đều có thể làm trong Rails và Laravel chỉ với chút cấu hình bổ sung”, nhưng Rails mặc định đã hỗ trợ Solid Queue (job) và Solid Cable (nhắn tin thời gian thực)

    • Từ góc độ một người mới chuyển sang Rails gần đây, SolidQueue thực sự rất đơn giản và có thể dùng ngay chỉ với thiết lập mặc định. Gắn thêm Solid Queue Dashboard thì còn có thể nhìn toàn cảnh trong nháy mắt

    • Riêng về nhắn tin thời gian thực thì tôi thấy cấu hình Solid Cable phiền hơn LiveView. LiveView còn tự lo luôn phần render, nên theo tôi nó đi trước việc phát triển bằng SolidCable của Rails khá xa

    • Mọi tính năng đều có thể làm bằng Rails. Đó là một framework rất đẹp, còn với Phoenix thì mọi thứ dễ và thoải mái hơn. Rất đáng thử một lần

    • Từ góc nhìn của người đã dùng cả Rails lẫn Elixir trong công việc, hai hệ thống này hoàn toàn không tương đương. Oban có cách dùng rõ ràng và việc chạy lại job cũng đơn giản, chỉ cần cập nhật cột trong DB là Oban supervisor tự xử lý tốt. Solid Queue không có cách dễ để chạy lại job đã thành công. Số lượng bảng cũng quá nhiều nên khó quản lý. Oban chỉ quản lý đơn giản hai bảng và hoạt động tự nhiên trong cùng ứng dụng, còn Solid Queue thì phải tham khảo nhiều bài blog rồi chỉnh thông số mới chạy ổn. Thiết lập mặc định còn thiếu. Nhờ đặc tính của Erlang/Elixir mà Oban có thể được làm rất đơn giản mà vẫn hoạt động xuất sắc, điều này đem lại niềm vui cho lập trình viên. Tôi đang dùng Solid Queue chỉ vì không còn cách khác

  • Tôi đã làm Rails từ rất lâu, nhưng dạo gần đây Phoenix/Elixir trở thành stack mặc định của tôi. Rails vẫn thật sự là tốt nhất để làm nhanh các ứng dụng CRUD, và ở điểm đó nó nổi trội rõ rệt. Nhưng khi độ phức tạp tăng lên và thời gian trôi qua, Phoenix/Elixir là công cụ tốt hơn về tổng thể

    • Sau khi LLM xuất hiện, các app đơn giản như vậy có thể được tạo ra trong vài phút. Tuy vậy, với những phần quan trọng cần chú ý thì Phoenix cho cảm giác có nhiều quyền kiểm soát hơn

    • Tôi muốn nghe cụ thể hơn về điểm nào hợp hơn và điều gì khiến bạn thấy nó vượt trội hơn

  • Câu “chúng tôi viết code để giải quyết vấn đề theo cách tối ưu nhất” cho thấy có thể cảm nhận được nhiệt huyết của tác giả. Tôi thì thuộc kiểu chỉ cần giải quyết được là khá hài lòng, nên có lẽ gắn với Rails hợp với mình hơn

    • Tôi đã bật cười khi đọc câu đó. Thực tế mà lúc nào cũng chỉ nghĩ đến tối ưu khi viết code thì cuối cùng công việc sẽ tiến rất chậm. Với tôi, lập trình vừa là kế sinh nhai vừa đôi khi là thú vui

  • Người ta hay nói cộng đồng Elixir nhỏ, nhưng họ đang nhắm tới trình độ khá cao với các thư viện rất tiên tiến. Nó làm tôi nhớ đến câu nói của một lập trình viên ngày xưa: “ít hơn thì tốt hơn”. Cũng có nhiều mã nguồn mở hay như elixir-dbvisor/sql

    • Ngược lại, hệ sinh thái JS lại quá lớn nên thấy mệt. Có 10 thư viện cùng tồn tại độc lập, không ai theo chuẩn nào cả. Nó giống như chọn món trong siêu thị lớn ở Mỹ, hoặc bị ép chọn trong một chuỗi nhà hàng kiểu Vercel

  • Nếu muốn cảm nhận được tinh hoa thực sự của Elixir thì tôi khuyên nên xem toàn bộ các video bài giảng của Saša Jurić

    • Saša Jurić là tác giả cuốn 'Elixir in Action', và cuốn sách đó cũng thực sự rất xuất sắc

  • Bài này tập trung vào Phoenix LiveView hơn là toàn bộ framework. Thực tế tôi không thích việc dù bỏ LiveView khỏi tùy chọn tạo project trong Phoenix thì mã LV mặc định vẫn còn sót ở nhiều chỗ

    • Tôi cũng đồng cảm với việc LiveView rất nặng tính áp đặt và có nhiều boilerplate. Tôi thích sự ngắn gọn và giàu biểu đạt của Elixir, còn LiveView lại cho tôi cảm giác ngược lại

  • Lý do duy nhất khiến tôi không chọn Elixir là thiếu type checker. Tôi tò mò không biết đã có thay đổi gì chưa
 
colus001 2025-10-18

Đúng là Livewire khá thú vị, nhưng chỉ cần UI hơi phức tạp một chút là nó sẽ thành địa ngục. Từ thời điểm đó, Phoenix cũng mất hẳn lợi thế của mình. Chu kỳ càng kéo dài thì càng vất vả, nên cá nhân tôi không mấy khuyến nghị nó.