Datastructure for broadcasting multiple message types

Question

We are thinking of moving from Pusher to Firebase. We are worried about how Pusher’s feeds will be featured in Firebase.

At Pusher, we have a channel for each user. Thus, the user may be in the channel user-1 , the other may be in the channel user-2 .

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

I think this is usually done as follows:

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

Here's the problem: user 1 and user 2 for the same page can have many common posts. Is there a way to reduce this duplication, as these messages can become quite large, sending and storing them per user can become expensive. Also, user 1 should not read messages from user 2.

It would be nice to do something like this:

 { 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: {}, } }, .... } 

But then, how will the security policy be applied, so that the message can only be read by the user_id specified in it.

Any pointers would be really appreciated.

Answer 1

If multi-cast is your use case and the messages are getting big, I would really separate the messages from the users and add links to the messages to the users you display.

 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 a beautiful day 2: The sun is shining 3: I feel good, I feel good 4: And nothing gonna stop me now 

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

I took the Web_page level to simplify things a bit. If you really need this level, you can add it back. The basic approach will remain the same.

In this case, security rules can use these message links to find out if use can read a specific message:

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

This rule defines security for any child in messages ( $message_id identified). We provide read access if $message_id is the link as a message to the current user ( auth.uid ).