消息广播的多播类型的数据结构 [英] Datastructure for multi-cast type of message broadcasting

问题描述

我们正在考虑从Pusher迁移到Firebase.我们正在考虑如何在Firebase中表示Pusher频道.

We are thinking about migrating from Pusher to Firebase. We are having troubling thinking about how Pusher channels would be represented in Firebase.

在Pusher中，每个用户都有一个频道.因此，一个用户可能在 user-1 频道中，另一个用户可能在 user-2 频道中.

In Pusher we have a channel per user. So a user might be in a user-1 channel, another might be in a user-2 channel.

然后我们的后端/服务器将通过 Pusher.trigger(message，['user-1'，'user-2'])向这两个用户发送一条消息.

Then our backend/server would send a message to both these users via Pusher.trigger(message, ['user-1', 'user-2']).

我认为通常可以这样做:

I think this would usually be done like this:

{
    web_page_1: {
        user_1: {
            messages: [{}, {}, ..],
        },
        user_2: {
            messages: [{}, {}, ..],
        },  
        ...
    },

    web_page_2: {
        user_2: {
            messages: [{}, {}, ..],
        },  
        user_3: {
            messages: [{}, {}, ..],
        }
    },
    ....
}

这里的问题是:同一页面可能的用户1和用户2有很多共同的消息.有没有一种减少重复的方法，因为这些消息可能会变得很大，因此每个用户发送和存储它们会变得很昂贵.同样，用户1也不能读取用户2的消息.

Here the problem is: User 1 and User 2 for the same page might have a lot of messages in common. Is there a way to reduce this duplication, since these messages can get rather large, sending and storing them per user can get expensive. Also User 1 should not be able to read the messages of User 2.

做这样的事情会很好:

{
    web_page_1: {
        message_1: {
            user_ids: [1,2,3]
            content: {},
        },
        message_2: {
            recipient_ids: [3,4,5]
            content: {},
        }
        ...
    },

    web_page_2: {
        message_1: {
            user_ids: [1,2,3]
            content: {},
        },
        message_2: {
            user_ids: [3,4,5]
            content: {},
        }
    },
    ....
}

但是，如何应用安全策略，使得消息只能由其中指定的user_id读取.

But then, how would the security policy be applied such that a message can only be read by the user_ids specified in it.

任何指针将不胜感激.

推荐答案

如果多播是您的用例，并且消息变大，我确实会从用户那里拆分消息，并像这样向用户添加消息引用您显示.

If multi-cast is your use-case and the messages get large, I would indeed split the messages from the users and add message-references to the users like you show.

Root
    Users
        provider:344923
            Name: Akshay Rawat
            Messages
                1: true
                2: true
                3: true
        provider:209103
            Name: Frank van Puffelen
            Messages
                1: true
    Messages
        1: It's a beautiful day
        2: The sun is shining
        3: I feel good, I feel good
        4: And nothing's gonna stop me now

在以上数据中，您可以看到您和我是用户. provider:... 是我们的uid，但可以是任何可以识别当前用户的东西.您已经收到消息1、2和3，而我仅收到消息3.我们俩都没有收到消息4.

In the above data you can see that you and I are users. The provider:... is our uid, but can be anything that allows you to identify the current user. You've received messages 1, 2 and 3, while I have only received message 3. Neither of us has received message 4.

我将Web_page级别简化了一下.如果您确实需要该级别，则可以将其重新添加.基本方法将保持不变.

您的安全规则然后可以使用这些消息引用来查看用户是否可以读取特定消息:

You security rules can then use these message-references to see if the use can read a specific message:

{
  "rules": {
    "Messages": {
      "$message_id": {
        ".read": "root.child('Users/'+auth.uid+'/Messages').hasChild($message_id)"
      }
  }
}

此规则定义消息下任何子级的安全性(由 $ message_id 标识).如果 $ message_id 被引用为当前用户的消息( auth.uid )，我们将授予读取访问权限.

This rule defines the security for any child under messages (identified by $message_id). We grant read access if the $message_id is references as a message for the current user (auth.uid).

这篇关于消息广播的多播类型的数据结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！