I am working on an app where I would like to attach a turbo_stream_from per element since the visibility of each element is variable and I’d like to avoid users receiving update events for items they don’t have access to. My question is what is the overhead on the server and client if there are 30-40 turbo_stream_from calls per page load? I noticed that each stream that a client attached to caused 2 log messages in the development log, which made me a little nervous about having a client attach to a large number of streams. Could anyone provide suggestions as to if this is reasonable or if I should find another solution?
This is a bad solution because most redis providers charge for each connection so this is very wasteful. It would be better to only render the content that will be visible and use turbo frames to add updates instead of turbo streams if possible. Another solution is having one turbo stream for the whole page and then broadcasting updates to specific sections of the page or target a single element
Thank you for your reply! I’m a little confused though, the server only has a single websocket cable connection open and all the streams route over it, correct? I don’t believe it makes a separate connection per stream so why would it have a separate redis connection per stream? Just to clarify I am currently rendering the page using turbo frames and pushing updates via turbo streams, the issue is I have a quite complex permissions model where pushing updates to everyone over the same channel could mean sending updates to someone that shouldn’t be able to see them which is a security issue.
The number of Turbo Streams doesn’t affect the number of Redis connections. Moreover, independently of the number of streams, you browser tab will only use a single Action Cable connection (i.e., aWebSocket connection). Action Cable multiplexes subscriptions; you don’t need to think about it.
And from the server perspective (if you use Action Cable), each process maintains a single Redis connection. No matter how many streams or WS clients you have.
However, there is still a concern regarding having too many subscriptions. You can easily cause a thundering herd problem during restarts: all the active clients will sends dozens of Action Cable commands (re-subscribing to streams) on re-connection, causing load spikes. That’s something to be aware of.