Rails ApplicationCable和Channels最佳实践？(Rails ApplicationCable and Channels best practice?)

Rails ApplicationCable和Channels最佳实践？(Rails ApplicationCable and Channels best practice?)

我目前正在使用Rails为反应和反应原生应用程序做准备。 令牌用于身份验证。

我的应用程序中有两个功能，需要WebSockets：

聊天系统（一次打开一个聊天） 通知系统

我看到两种实现WebSockets的方法：

两个独立的渠道

第一个频道：当客户端打开应用程序时我订阅的NotificationChannel ，然后我广播，如果需要的话

第二个频道：我在聊天时订阅的ChatChannel ，代码如下：

class ChatChannel < ApplicationCable::Channel def subscribed authorize_chat_room_id(params[:chat_room_id]) # stream_from "chat_channel_#{params[:chat_room_id]}" end # here methods for receiving data from client # maybe some other methods for tracking if sb is typing and so on # private authorize_chat_room_id method end

在这种情况下，用户最多订阅2个频道，并且在订阅聊天时仅执行一次授权。

在这种方法中，我只授权用户一次，当他订阅频道时，我不知道如何打开2个频道而不是1，影响服务器的性能。

一个频道

将调用单个通道： PersonalChannel ，并将处理所有信息流，代码看起来像这样：

def subscribed stream_from "personal_channel_#{current_user.id}" end def send_message(data) if authorize_chat_room_id(data['chat_room_id']) #create message end end def start_typing(data) if authorize_chat_room_id(data['chat_room_id']) # some broadcast end end

当我进行广播时，我会发送有效负载，例如类型（例如'MESSAGE_SEND'），并且基于此，如果聊天打开，客户端将打印消息。

这种方法的优点是，当发送消息时，我只能向一个用户广播，我不会从频道收到消息。 但在这种情况下，我每次都要授权执行一个动作。

我的问题是，哪种解决方案在性能方面会更好，什么是普遍接受的方法（使频道非常通用或使每个频道处理单一任务）？

I am currently using Rails to prepare backed for reacting and react-native applications. The token is used for authentication.

I've got two features in my application, which require WebSockets:

Chat system(one chat open at a time) Notification system

I see two ways to implement WebSockets:

Two separate channels

First channel: NotificationChannel to which I subscribe when client opens application and then I broadcast sth if it is required

Second channel: ChatChannel to which I subscribe when I open a chat, the code would look as follows:

class ChatChannel < ApplicationCable::Channel def subscribed authorize_chat_room_id(params[:chat_room_id]) # stream_from "chat_channel_#{params[:chat_room_id]}" end # here methods for receiving data from client # maybe some other methods for tracking if sb is typing and so on # private authorize_chat_room_id method end

In this scenario user is subscribed maximally to 2 channels and authorization is performed only once when subscribing to chat.

In this approach, I authorize only once the user, when he subscribes to channel, however, I don't know how having 2 channels opened instead of 1, affects performance on the server.

One channel

The single channel would be called: PersonalChannel, and would take care of all information flow, the code would look sth like this:

def subscribed stream_from "personal_channel_#{current_user.id}" end def send_message(data) if authorize_chat_room_id(data['chat_room_id']) #create message end end def start_typing(data) if authorize_chat_room_id(data['chat_room_id']) # some broadcast end end

And when I would broadcast, then I would send in the payload for example type(ex. 'MESSAGE_SEND'), and based on that, react client would print the message if chat would be open.

The advantage of this approach is that when sending the message I can broadcast only to one user and I won't get back message from the channel. But in this case, I have to authorize each time performed an action.

My question is which solution would be better in case of performance and what is generally accepted approach(to make Channels very general or to make each Channel take care of single task)?

最满意答案

在这个问题上，我建议您考虑优先考虑代码维护问题而不是性能。

channels的概念允许我们将出版商与消费者分开。 这简化了大量代码并有助于分离关注点。

例如，在聊天室中发帖的用户不需要知道（也不管理）有多少人订阅该聊天室，也不需要知道他们是谁。 这些问题现在由pub / sub系统而不是用户处理。

这种关注点分离使得添加或删除聊天成员变得更加容易（您不需要更新每个用户，只需更新pub / sub系统）。

这种分离还可以防止存储多个数据副本（发布/订阅系统只保存有效副本）。

从长远来看，通过将所有数据整合到一个PersonalChannel ，您将重新引入发布者和使用者之间的耦合 - 这将增加复杂性并使维护模式随着时间的推移变得困难。

在聊天室示例中，每个用户都需要获取所有会议室成员的副本，并将每封消息发送给所有用户。 这增加了（成员列表的）副本数量，并引入了同步问题。

这种方法的优点是，当发送消息时，我只能向一个用户广播，我不会从频道收到消息。 但在这种情况下，我每次都要授权执行一个动作。

这个优势实际上是您可以通过订阅每个用户到个人频道以及其他频道使用第一种方法轻松实现的，订阅三个频道而不是两个频道。

On this issue, I would suggest that you consider prioritizing code maintenance concerns over performance.

The concept of channels allows us to decouple publishers from consumers. This simplifies a lot of code and helps with separation of concerns.

For example, a user posting in a chat room wouldn't need to know (nor manage) how many people are subscribed to that chat room, nor who they might be. These concerns are now handled by the pub/sub system rather than the user.

This separation of concerns makes adding or removing chat members much easier (you don't need to updated every user, you only need to update the pub/sub system).

This separation also prevents multiple copies of the data from being stored (the pub/sub system holds the only valid copy).

In the long run, by consolidating all the data into a single PersonalChannel, you'll be reintroducing the coupling between publishers and consumers - this will increase complexity and make maintenance mode difficult over time.

In the chatroom example, each user will need to grab a copy of all the room's members and send each message to all users. This increases the number of copies (of the member's list) as well as introduces synchronization concerns.

The advantage of this approach is that when sending the message I can broadcast only to one user and I won't get back message from the channel. But in this case, I have to authorize each time performed an action.

This advantage is actually something you can easily achieve using the first approach by subscribing each user to a personal channel as well as the other channels, subscribing to three channels instead of two.