LiveView, công nghệ kết hợp tốt nhất với Svelte

Sự kết hợp giữa LiveView và Svelte

• LiveView mang đến một cách tiếp cận độc đáo để xây dựng ứng dụng web.
• Máy chủ giữ trạng thái, xử lý hành vi của frontend ở backend và cập nhật DOM theo từng bước.
• Độ phức tạp của SPA đến từ độ phức tạp của hệ thống phân tán, và LiveView mang lại trải nghiệm client phong phú mà không cần microservice frontend.

Những điểm khó của LiveView

• Trạng thái phía client là điều không thể tránh khỏi, và độ trễ giữa máy chủ và người dùng cũng không thể loại bỏ.
• LiveView để máy chủ đảm nhận nhiều thay đổi DOM, nhưng không thể kiểm soát mọi thứ.
• LiveView có ba loại component: LiveViews, LiveComponents và Components.
• Việc refactor giữa LiveView và LiveComponents phiền phức hơn dự kiến.

Định hướng còn mơ hồ của LiveView

• LiveView thường tạo cảm giác rằng nó đang thiếu một điều gì đó.
• LiveView có nhiều điểm chung với các framework frontend hiện đại, nhưng cần nhận ra sự khác biệt và tiếp cận vấn đề theo cách khác.

LiveView + Svelte

• LiveSvelte cho phép render component Svelte trong LiveView.
• Backend kiểm soát props của component frontend, và cả frontend lẫn backend đều có trạng thái.
• Có một kênh giao tiếp riêng tư, hai chiều giữa frontend và backend.

Những đặc tính đột phá của LiveSvelte

• Việc phân chia trách nhiệm giữa backend và frontend rất rõ ràng, và độ phức tạp được tập trung ở phía máy chủ.
• LiveView phát huy tốt nhất vai trò frontend cho backend, cung cấp một tiến trình backend có thể render component frontend và duy trì trạng thái.

Ý kiến của GN⁺

• Sự kết hợp giữa LiveView và Svelte giúp tách biệt hiệu quả việc quản lý trạng thái giữa máy chủ và client, đồng thời cho phép nhà phát triển xây dựng ứng dụng nhanh hơn và trực quan hơn.
• Công nghệ này có thể đặc biệt hữu ích với các ứng dụng web nơi tương tác thời gian thực là quan trọng, và có thể góp phần cải thiện trải nghiệm người dùng.
• Tuy nhiên, vì độ trễ với máy chủ có thể ảnh hưởng đến trải nghiệm người dùng, tối ưu hiệu năng và bố trí máy chủ theo khu vực có thể là những yếu tố cần cân nhắc quan trọng.
• Sự kết hợp giữa LiveView và Svelte mang đến một mô hình mới cho các nhà phát triển đã quen với cách xây dựng SPA truyền thống, với tiềm năng giảm độ dốc học tập và nâng cao hiệu quả phát triển.
• Khả năng đồng bộ trạng thái thời gian thực và giao tiếp hai chiều mà công nghệ này cung cấp có thể là lựa chọn hấp dẫn cho các công cụ cộng tác, dashboard hoặc các ứng dụng xử lý dữ liệu thời gian thực.

[GN⁺]

Ý kiến trên Hacker News

• Một trong những mẫu được dùng trong game video nhiều người chơi là có phần mã về cơ bản chạy ở cả phía client lẫn server.

  • Mã phía client chạy như một dự đoán của trạng thái server.
  • Khi nhận được trạng thái server, trạng thái client sẽ bị ép áp dụng theo.
  • Trong game, “dự đoán” là cách diễn đạt phù hợp, vì client có thể đoán khá tốt kết quả của đầu vào, nhưng không thể chắc chắn do không biết đầu vào của người chơi khác.
  • Mô hình này cũng có thể được dùng để phản hồi ngay lập tức với đầu vào của client trong khi chờ trạng thái chính thức từ server (ví dụ: bật/tắt dropdown, hiển thị loading spinner).
  • Cũng có nhiều trạng thái client không chạy trên server (ví dụ: hệ thống hạt, ragdoll — những thứ không cần giống hệt trên mọi client và không tương tác với đầu vào/vật lý của người chơi khác).

• Tôi đã có một bài trình bày tại ElixirConf 2022 về cách kết hợp LiveView và Svelte, và những người đóng góp cho live_svelte đã giúp biến điều đó thành hiện thực.

  • Trạng thái phía client luôn cần thiết, đặc biệt với các ứng dụng có UX phong phú.
  • Ở thành phố New York, kết nối mạng đặc biệt là khi đang di chuyển không phải lúc nào cũng được đảm bảo.
  • Khả năng dùng pubsub của Phoenix để phản ứng và đẩy tới client các thay đổi trạng thái phía server phát sinh từ server khác là cực kỳ mạnh mẽ.

• Khi có hàng mới đi vào, LiveView sẽ cập nhật client nên chỉ cần push vào bảng.

  • Tôi khuyên không nên dùng cách này trong các ứng dụng doanh nghiệp có các hàng tương tác.
  • Có thể xuất hiện độ trễ nhận thức khiến người dùng bấm nhầm, gửi email cho sai khách hàng hoặc hoàn tiền cho sai giao dịch.
  • UX tốt là dùng banner kiểu nhãn dán để báo dữ liệu đã thay đổi, hoặc khi cần gấp thì chỉ thêm hàng mới mà không làm thay đổi vị trí cuộn.

• Chúng tôi dùng Svelte cùng với LiveView trong BeaconCMS.

  • Đây là một trường hợp sử dụng tốt khi bạn muốn kiểm soát UI chi tiết hơn ở phía client.
  • Dù dùng Phoenix thì LiveView cũng không phải lúc nào là câu trả lời, đôi khi trang render tĩnh là hoàn toàn ổn.
  • Tôi khuyên đừng tiếp cận theo kiểu tất tay hoặc không gì cả với mọi thứ.
  • Như bài viết đã chỉ ra, có một vài trường hợp sử dụng tốt khi đi chệch khỏi “cách làm LiveView”.
  • Nếu có round trip 1000ms thì sẽ có những cân nhắc khác, nhưng có thể không dùng được server đặt theo khu vực vì chi phí hoặc lý do khác, nên thêm quản lý trạng thái phía client có thể là lời giải.

• Thay vì quản lý trạng thái trên client, bạn quản lý trạng thái ở cả client lẫn server.

  • Khó mà xem đây là một cải tiến; đúng là nó giúp không cần xây thêm một API khác, nhưng như vậy không có nghĩa là tốt hơn.

• Giới hạn của cách tiếp cận này nằm ở tốc độ ánh sáng: server có giới hạn về mức độ gần với người dùng.

  • Bước tiếp theo là biên dịch server sang WebAssembly và gửi nó cho client để render phản hồi một cách lạc quan cho tới khi server thực sự trả về.
  • Nghe có vẻ hơi điên, nhưng tôi thực sự đã làm thành công điều này trong một dự án và trải nghiệm đó giống như phép màu.

• Tôi là người tạo ra LiveSvelte, nếu có câu hỏi thì cứ cho tôi biết.

• Nói chung tôi luôn muốn xây ứng dụng theo mô hình này: hướng sự kiện, cập nhật thời gian thực hai chiều cùng với server, sự kiện có thứ tự, trạng thái cục bộ và từ xa...

  • Tôi chưa biết về LiveView và cũng chưa từng dùng ngôn ngữ họ Erlang, nhưng rõ ràng họ đã tìm ra điều gì đó.
  • Mô hình request-response truyền thống gây ra rất nhiều vấn đề về tính nhất quán và dữ liệu cũ.
  • Một suy nghĩ đầy hy vọng nhưng có lẽ gây tranh cãi: nếu 10 năm qua là về việc đưa các khái niệm FP vào ngôn ngữ chủ đạo, thì mong rằng 10 năm tới sẽ là về việc đưa lập trình hướng thông điệp có trạng thái (reactive?) vào toàn bộ stack chủ đạo.

• Tôi đang dùng các Stimulus controller có thể tái sử dụng cùng với LiveView trong ứng dụng, và cách này cũng hoạt động rất mượt.

  • Nhìn chung, xây dựng bằng LiveView là một niềm vui, nhưng càng dùng trong các tình huống thực tế tôi càng nhận ra lợi thế của framework HTTP không trạng thái.
  • Các framework như Hotwire cho hiệu năng vượt trội hơn và khả năng phục hồi tốt hơn khi tái kết nối, đồng thời tránh được nhu cầu phải đặt server gần người dùng hơn.

• Dự án rất tuyệt! Tôi vừa phát hành một tập Svelte Radio về nó.