12/08/2018, 13:49

Giới thiệu về rails 5.0 với Action Cable -part1

Rails 5: Action Cable - Bạn hay thù? Tóm tắt: Action Cable là một trong những tính năng chính của rails 5. Nhưng Action Cable làm được j cho dev? Có phải web sockets thực sự hữu dụng như mọi người nói. Bài viết này không phải là một bài hướng dẫn, thay vào đó chúng ta sẽ nhận được những lí do ...

Rails 5: Action Cable - Bạn hay thù?

Tóm tắt: Action Cable là một trong những tính năng chính của rails 5. Nhưng Action Cable làm được j cho dev? Có phải web sockets thực sự hữu dụng như mọi người nói.

Bài viết này không phải là một bài hướng dẫn, thay vào đó chúng ta sẽ nhận được những lí do cho việc tại sao lại dùng Action Cable.

I. Đừng ấn nút refresh

Một trang Web được xây dựng xung quanh các HTTP request. Trong một ngày đẹp trời, bạn request một trang web (với method GET) và nhận được response từ trang web đó.Chúng tôi tạo ra một phương thức mở rộng (REST) để tạo ra một trang web dựa theo request và chỉnh sửa resource trên server.

Điều quan trọng của việc nhận định HTTP request là stateless - để chúng tôi biết được ai đang request và request điều j.Nếu không đọc được nội dung của request thì thực sự không có cách nào để biết request thuộc session nào.Thông thường, trong rails chúng tôi làm điều này với một secure "signed" cookie. Một Cookie có nghĩa là client không thể xáo trộn giá trị quan trọng, nếu bạn muốn ngăn chặn việc hack.

Khi web ngày càng phong phú hơn với các dữ liệu media: video, audio... thay vì chỉ text, Chúng tôi mong muốn một kết nối không bị gián đoạn giữa client và server.

  • Client cần gửi thông tin nhanh chóng đến server: Môi trường với băng thông cao, như trò chơi online dựa trên brower, cần client và server trao đổi một vài message mỗi giây. Hãy tưởng tượng việc cố gắng implement một đoạn networking code cho game bắn súng. Đôi khi điều này được gọi là một "full-duplex" hoặc một "bi-directional" comminication.
  • "Live" data: Các trang web bắt đầu có các "live" elements, như việc các đoạn comment sẽ tự động cập nhật khi có một comment mới (mà không refresh trang). Ví dự như các chatroom, dữ liệu chứng khoán ...Chúng tôi muốn trang web tự động cập nhật chính nó khi có dữ liệu thay đổi từ server mà không cần người dùng nhập input. Đôi khi nó được gọi là "realtime" application với ý nghĩa là thay đổi liên tục. Thực tế chúng không thay đổi liên tục (thay đổi trên mỗi nano giây) mà sẽ thay đổi một lần mỗi phút hoặc lâu hơn. Tôi thích thuật ngữ "live" vì lí do này.
  • Streaming: HTTP tỏ ra không phù hợp cho streaming data. Trong nhiều năm streaming data cần phải require các plugins của bên thứ ba (như RealPlayer). Ngay cả bây giờ, streaming data vẫn là một nhiệm vụ phức tạp nếu không có Websockets.

II. The Road to Websocket

Một số giải pháp vẫn đang được sử dụng để giải quyết vấn đề "realtime":

  • Polling

    Polling là việc client hỏi server trên mỗi một khoảng thời gian quy đinh (ví dụ là mỗi 3 giây) : Điều này có nghĩa là với mỗi 3 giây client lại hỏi server xem có dự liệu mới không. Nếu có dữ liệu mới thì thông tin sẽ được cập nhật.

    Ưu điểm của phương pháp này là dễ thiết lập, nhưng nhược điểm lớn của nó là độ trễ cũng như tăng đáng kể lượng tải của server. Nên giải pháp này là không phù hợp cho các ứng dụng "realtime".

  • Long-polling

    long-polling có một chút giống polling, nhưng không có khoảng thời gian thiết lập giữa các request. Clients gửi một request đến server để nhận dự liệu mới, nếu server có dữ liệu mới thì server sẽ gửi dữ liệu về cho client như bình thường.Nếu không có dữ liệu mới, nó sẽ giữ request luôn mở, và khi có dữ liệu mới thì server sẽ lại gửi response về cho client.

    long-polling rất tốt nếu các dữ liệu không thay đổi quá nhanh. Ví dụ về chatroom trên thì nếu 45 giây mới có 1 comment mới thì thay vì 15 request từ client lên server thì server chỉ phải mở một kết nối.

    Tuy nhiên giải pháp này sẽ nhanh chóng sụp đổ nếu dữ liệu thay đổi quá nhanh.

  • Server-sent Events (SSEs)

    server gửi một sự kiện là kết nối 1 chiều từ server đến client. client không thể sử dụng SSEs để gửi dữ liệu ngược trở lại server.

    Sử dụng các server-side events khá đơn giản từ phía client (thông qua Javasript). Bạn thiết lập một đối tương Eventsource, xác định một callback onmessage mô tả những gì bạn sẽ làm khi nhận được một message mới từ server

    Server-send event được suport từ rails 4.0 thông qua ActionController :: Live.

    Phục vụ client với SSES đòi hỏi một kết nối liên tục. Điều này là không thực sự ổn vì bất các appserver đều có timeout.

III. Kết luận

Có lẽ giờ là lúc tìm đến một giải pháp khác cho một ứng dụng "realtime", và đó là lúc ta nghĩ tới Websockets. Thông thường, khi làm với websockets thì dev sẽ nghĩ ngay đến Nodejs, tuy nhiên websockets là một trong những tính năng chính của rails 5 mới được release. Và chúng ta sẽ tìm hiểu về Websockets trong rails 5 ở phần 2 của bài viết.

IV. Nguồn tham khảo

https://www.nateberkopec.com/2015/09/30/action-cable.html

0