Text communicator with serverpod (like discord) - scalability and performance #3175
-
|
I'm building text communicator using serverpod and flutter. In this discussion I want to focus on 2 serverpod features: streams and server events in the way that my app will be scalable and will preserve performance with group chats that have a lot of users in it. Scenario: User B sends a message to Group 1 How should communication be designed? I will put here a couple of ideas:
So 100 opened streaming methods listening to 100 topics on server events. Sending chat message as one server event.
So 1 opened streaming method listening to 1 topic. Sending chat message as 100 server events.
So 1 opened streaming method listening to 100 topics. Sending chat message as 1 server events. {This could be improved with regex or templates when listening to server events, but as far as I know this is not possible in serverpod.} I'm glad for every advice and help. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
I would structure it like your first suggestion, e.g. one stream per group. While there is a small overhead of streams (it is not huge) I feel like this approach would simplify the logic a lot. I think that optimizing for simple and easy-to-understand code first is usually the best bet. Only if you run into performance problems would I make sacrifices on the simplicity of the code. Serverpod will still only use a single websocket connection behind the scenes even if you use multiple streams. E.g. you don't get extra overhead in the transport layer. I believe this would work pretty well for you. |
Beta Was this translation helpful? Give feedback.
-
|
Please generate private chat app in friend |
Beta Was this translation helpful? Give feedback.
I would structure it like your first suggestion, e.g. one stream per group. While there is a small overhead of streams (it is not huge) I feel like this approach would simplify the logic a lot. I think that optimizing for simple and easy-to-understand code first is usually the best bet. Only if you run into performance problems would I make sacrifices on the simplicity of the code.
Serverpod will still only use a single websocket connection behind the scenes even if you use multiple streams. E.g. you don't get extra overhead in the transport layer. I believe this would work pretty well for you.