We are researching the possibility of developing the twitch extension support with our game. And we need to scope out how much work it could take, so we can properly plan the development.
Extension needs: Player plays the game and the extension displays some additional information from his current game. It would be just extra info. The twitch viewers could explore this information but could not affect it in any way / we would not need to store any user actions/interactions from viewers.
Question:
Do we need to run backend software on our servers or can the extension communicate with the data from the players computer directly?
Aka do we need to implement:
A: game → our servers → twitch extension
or
B: game → twitch extension
In most situations you would need a server for your example to work.
The difficulty is getting data from the game, to the viewers, in a way that doesn’t expose the broadcasters IP to viewers. Without a server, this pretty much limits you to requiring the broadcaster having a tab open with the Extension running, so that the Extension can connect to the game running on their machine, and broadcast data from the game on Extension PubSub (which is limited to 1msg per second, and 5KB per message).
With a sever though, the game can form an outbound connection to your server, rather than requiring it to listen to http or WS requests if you was doing it without a server. With that connection, the game can send as much data as it likes as it’s not controlled by Twitch. Once the data is on your server, you can then either broadcast it over Extension PubSub to viewers if it fits within the rate limit, or your server can act as a HTTPS API that viewers can poll for that data, or connect to with a websocket connection that data will be sent on. Having a server handle all of this would also mean it continues to function even if the broadcaster doesn’t have the Extension running themselves.
Question to the pubsub, if we broadcast a <message> at timestamp 00:20 and a new viewer joins the streamer at 00:25 does he automatically loads the latest <message>?
Btw the PubSub way would be awesome as it would require really low amount of resources on our side regardless of the amount of viewers.
Extension PubSub is separate from the general Twitch PubSub. On your server you would use the Send Extension PubSub Message API endpoint. That reference also includes the links on how to sign the JWT that will be used.
There’s no way to retrieve historical messages, so your options would be to either have the viewers Extension be in a ‘loading’ state until it receives a broadcast from your server (which could mean sending broadcasts even if the data hasn’t changed, just to update any new viewers).
Alternatively you could maintain the current state on your server, and have the viewer make a single HTTPS request to your server, which would then verify the JWT from the user (to ensure it’s legitimate Extension traffic, and to see what channel they’re viewing on) and then respond with the most recent data for the channel they’re watching.
There’s pro’s and cons to both methods, as the latter would be more responsive as the user isn’t waiting for a broadcast, but the downside being your server would have to listening for incoming requests from users, and during a raid, or a high profile streamer going live with your extension, this can potentially be a large flood of traffic in a short space of time where as if they just wait for the next broadcast message on PubSub only the streamers will be connected to your server, not viewers.
This has a lower rate limit than PubSub broadcasts. So if you’re sending 1 broadcast per second than that will have fresher data than the config service which could be stale and not have the latest message.
It all comes down to whatever you think is best for your specific situation and workflow.
