Tôi luôn muốn trò chuyện trong thời gian thực.

Tôi đã làm điều đó nhiều năm trước trong PHP + Ajax + Mysql và làm hỏng máy chủ của tôi. Sau đó, tôi đã thử với Flash + một tệp văn bản. Tôi đã từ bỏ và không cố gắng trong 10 năm. Nhưng gần đây tôi đã nghe nói về webhook và websockets. Và cả hai đều có vẻ là một cách để làm điều đó nhưng tôi không thực sự hiểu rõ sự khác biệt. Bất cứ ai có thể giải thích?

Webhooks

Webhook dành cho giao tiếp máy chủ với máy chủ. Chúng hoạt động bởi một máy chủ nói với máy chủ khác rằng nó muốn dữ liệu được gửi đến một url nhất định khi có điều gì đó xảy ra.

Bài viết này nói về một số cách sử dụng webhook trong các dịch vụ phổ biến. Tổ chức này nói rất nhiều về việc sử dụng chúng trong ngữ cảnh của các API RESTful.

Websockets

Websockets là (thường) để giao tiếp giữa máy chủ với trình duyệt. Máy chủ lưu trữ một máy chủ websocket và các máy khách có thể mở kết nối đến máy chủ đó. Cách này phổ biến hiện nay chủ yếu vì nó nhanh hơn và ít tốn tài nguyên hơn so với các cách giải quyết vấn đề cũ hơn, như long-polling / COMET .

Có thể kết nối 2 máy chủ bằng cách sử dụng websockets , nhưng đó không phải là những gì chúng thường được sử dụng.

Sự nhầm lẫn

Mặc dù một trong số này là máy chủ (độc quyền) và một là (chủ yếu) là máy chủ trình duyệt, các công nghệ này thường được thảo luận ở cùng một nơi, gần giống như chúng đang giải quyết các vấn đề giống nhau. Nếu bạn nhìn lên chuỗi đủ cao, bạn sẽ thấy rằng cả hai đều giải quyết vấn đề giao tiếp "thời gian thực", nhưng chúng giải quyết các khía cạnh khác nhau của vấn đề này theo những cách rất khác nhau .

Một tình huống có thể có sự so sánh trực tiếp là nếu bạn đang xây dựng một API sẽ được sử dụng bởi máy chủ bên thứ ba. Trong tình huống đó, bạn có thể cung cấp API webhook hoặc API websocket . Cả hai đều cho phép bên thứ ba nhận cập nhật nhanh chóng:

• Nếu bạn chọn webhook, bên thứ ba đó sẽ vẫn phải tìm ra cách để đẩy những thay đổi mà bạn đang nói với họ lên trình duyệt của khách hàng của họ.
• Nếu bạn cung cấp API websocket, bên thứ ba chỉ có thể thiết lập trang web của họ để mỗi người dùng của họ kết nối trực tiếp với API websocket của bạn và máy chủ của họ phải thực hiện ít công việc hơn.

Dưới đây là một số thông tin bổ sung để lựa chọn giữa webhook và websockets.

Truyền thông từ máy chủ đến máy chủ qua websockets đã trở nên phổ biến với một thế hệ ứng dụng chatbot mới. Giờ đây, nhiều chatbot chạy trên websockets cung cấp lợi thế chính là không yêu cầu URL công khai cho các bot nội bộ, riêng tư. Trong môi trường này, sau đây là một số nguyên tắc về thời điểm cân nhắc sử dụng webhooks so với websockets.

Websockets

• Nếu ứng dụng của bạn là ứng dụng trình duyệt, hãy sử dụng websockets vì ứng dụng của bạn không thể nhận webhook.
• Nếu ứng dụng của bạn là ứng dụng máy chủ nhận thông báo từ một dịch vụ qua Internet và bạn không muốn mở tường lửa của mình, hãy xem xét websockets. Một số công ty yêu cầu xem xét bảo mật thông tin trước khi mở các kết nối như vậy.

Webhooks

• Nếu ứng dụng ứng dụng máy chủ của bạn cần tạo nhiều đăng ký, hãy chuẩn bị để xử lý khối lượng kết nối websocket đang mở tới máy chủ của bạn ( xem bài viết này để biết 1 triệu kết nối websocket ) hoặc chuyển sang webhook. Một số chatbot phổ biến đã chuyển từ websockets sang webhooks để cải thiện khả năng mở rộng.
• Nếu ứng dụng máy chủ của bạn chạy dưới dạng một chức năng đám mây trên (AWS Lambda, Google Cloud Functions, v.v.), hãy sử dụng webhooks vì ứng dụng của bạn sẽ không giữ kết nối websocket mở.
• Nếu ứng dụng máy chủ của bạn đang chạy trên tầng miễn phí Heroku, hãy sử dụng webhooks vì Dyno của bạn sẽ chuyển sang chế độ ngủ và phải ngủ trong 6 giờ mỗi ngày, trừ khi bạn hướng dẫn máy chủ của mình ngủ theo cách thủ công.