I would like to know if the attached workflow works with the PubSub service.
Basically, our backend service needs to keep our extension overlay updated with what is happening to the game being broadcasted. The game itself has its own implementation of notifying us (our backend service) when some or relevant statistics of the game has been changed. In turn, we would like to propagate the changes to the users that used our twitch overlay extension. This is the idea that we thought would be ideal for such case. But I am unsure if this is possible and how? I have gone thru the documentation but I can’t find any example that has sort of “custom topic” being communicated thru the PubSub service.
There are no custom topics for Extension PubSub, if you want your backend to send data to your frontend you would use the Send Extension PubSub Message endpoint.
This allows your Extension to send up to 100 messages per minute per channel, each of up to 5KB, and either broadcasted to all users on the channel or whispered to specific users. Within the frontend you would use the Listen Helper function so that the client could listen for those messages.
The content of that message can be whatever you like, so in your case you would likely want to send the data to keep your Extension overlay updated, and maybe some metadata such as type of event so the client know what type of data it’s receiving and what to do with it.
@Dist thank you so much for your inputs. I see. So I have been looking into the wrong section then. As for the messages limit, is there any way it can be increased? I don’t think 100 messages per minute would suffice our needs unfortunately.
It is not possible to increase the limit of Extension Pubsub.
If your Extension needs more than what Twitch Extension PubSub allows for you would need to use your own service, such as having Extension clients connect directly to your backend over a Websocket or periodically polling a HTTP endpoint. By using your own system you would not be constrained by Twitch’s limits.
100 per minute is enough for a game sync message every second. (Such as player location)
With 40 left each minute to send something else (such as profile updates)
In the example of my FlightSimTrack Extension, I send
Player location and aircraft around the playerevery second 60 per minute
Leaving me 40 per minute to update other data such is game radio frequencies selected or other plane information or map waypoints as a lower poll rate.
I’m also polling data out of the game at 1hz so sending to Twitch at 1hz works quite well
Viewers don’t need smooth/instant up to date data, in my example of plane location on a map.
And for example if you wanted to delay data by the viewers own HLS offset, you’d have to queue up that data until the appropriate trigger time, so you’d be storing a lot of information in memory if you are running quicker than 1hz (FlightSimTrack doesn’t but I have other extensions that do delay draws)
So yeah you might have a user case that needs more frequent updates (than 1hz) in pockets of burst, and theres room for that on Extension PubSub, but a primary update rate faster than 1hz. then you are making the users client draw the extension view a lot more often. And could be a detriment to the browser tabs ability to play the video itself and/or other drawing actions such as chat. Which could lead to not passing review if you extension is constnatly crashing or leading to a poor viewer interaction for memory leaks/overuse. (I’ve had that happen before when I left a bug in my sender and it dumped 100 messages on the client in a very short time and all hell broke loose)
So is faster than 1hz constant that exceeds Twitch’s limits a good idea? Depends on how much data you are batting around.
But as Dist notes, you do not have to use Extension PubSub, it’s a tool to help developers scale their extensions without having to worry about needing to scale backends based on viewer connections.
You can use whatever you want as long as the connection is over SSL, and complies with the CSP.
Good point. I have actually given this a little thought and me and my colleague have confirmed that we only refresh the data (broadcast) per second. Therefore, the limit is more than enough actually. Thanks for your inputs guys @BarryCarlyon@Dist We’ll keep note on this for sure!
