Laravel活动动态频道名称

Question

我正在我的应用程序中创建一个实时通知功能,该功能将使用Pusher在收到通知时自动通知用户(通过用户所遵循的某些操作创建通知).

我知道如何设置事件并进行广播,但我对于广播这些通知的频道感到困惑.情况将是用户A跟随许多其他用户,但也有许多粉丝本人.

如果用户A发布新内容,我们可以触发一个事件,向他刚发布内容的所有关注者广播通知.这里的问题是,我们在"user.A"上播放这个频道吗？这意味着跟随用户A的每个其他用户将不得不一直订阅该频道以及他们关注的每个其他用户的频道.

那么,更有效的是,可以在数百个不同的频道(每个频道代表一个用户A的关注者)之间动态广播,或者每个用户应该自动收听可能数百个不同用户的频道？

不确定哪个更有效率.谢谢!

Answer 1

First, simplicity and potentially the 'how-to'. In the example, that the OP gave typically instead of what I would consider something like a 'Unique Event Subscription' vs one channel for many events. This does depend on use case and matters of scale. I would assume the typical use case that creating a in-house single channel event listening approach would be best. This being that basically the messages passed are the event types and the data is that stored in an event model (not laravel's but proprietary). This has the major advantages in that you can leverage enums, flexibility, etc... while maintaining simplicity. However, and to the second thought is pricing and such...

Second thought, is that even since the time that this was posted pusher has a cap on the amount of users allowed to be concurrently and actively listening on that socket driven by PersonA in the given example. I believe that number to be 100. While my first point may maintain a simpler in-house approach cost does play a factor. So even if pusher did not cap the active concurrent users the amount events generated and sent are coupled to the amount of active users. Therefore, if a user wasn't too popular and only had 3 followers, but 100k people are on that active socket to update 3 people costs 100k messages in terms of billing. I will share an image to confirm that thought...

Last point, which has been resolved since the OP originally asked their question was the introduction of presence channels. The give the ability to show activity via whispering etc. They are also more based or geared to the sharing of subscribed "entity" data information, like user or business etc... Versus being built for handling message/event types with data and handling those responses with data learned in real-time. (I stated that last line oddly to keep in mind if data can be found in the DB or backend, it reduces the drive and need for real-time notification or broadcasted events.

Other alternatives for broadcasting that may have different rules are BeyondCode WebSocket Server (https://github.com/beyondcode/laravel-websockets), Ably (https://ably.com/), and Soketi (https://docs.soketi.app/). Also others can be found https://laravel.com/docs/10.x/broadcasting#open-source-alternatives