Decision about Extensions ON/OFF feature Architecture

I’m doing a feature for my extension which allow the Streamer show or not show the extension. A must have one, I think. Basically my extension has a Configuration Page which handle this feature: When the streamer turn it on, it gonna display in the viewer screen.

As a mostly backend dev, my first thought was, “ok, I send a { isRunning: true } object to my EBS and then from there dispatch the Pub/Sub request to the listening queue”. But it sounds me like an overkill, maybe because I’m used to use REST APIs to storage entities and this case is just to notify a state change.

If it was a typical react application I guess I would access it by the React’s Context API, but the architecture of the Twitch Extensions do not allow me to wrap all the components (Overlay, Config, Panel, etc) in a unique App, because the extension could be not rendered properly.

Do it fast
“Just send it in front bro”. Just hit the Twitch Pub/Sub API from your Component’s method and that’s it.

Why I think that handling in the backend is ok?
Because if the backend handles it, the logic will be hide behind the ON/OFF feature, for example the communication method (Pub/Sub API) which need to send sensible headers like CliendID and token.

A pain point?
Sending to the backend adds a http request for every time the streamer ON/OFF the extension I could sound expensive, but if you think the use case of this, I only may occur 6/8 times per stream (3 or 4 times ON and OFF the extension). It only causes laugh to a http server.

Well, I explained what I think about this point, but I’m searching for someone that can tell me if this makes sense or there is a better solution or I’m just talking crazy things.

Thank you in advance guys!

You’re on the right track!

I would read the setting on load from your EBS or Config Segment and use PubSub to push any live changes to all the viewers.

I’d prefer letting the user actually turning off/on the extension, as it’s possible the only reason to turn it off is to put another extension in it’s place, or it’s a game specific extension and the streamer is not playing that game.

Alternatively what you and @dash describe mentions makes sense.

  • Store on/off using the configuration service,
  • when you update on off
    • store the payload in the configuration service,
    • also send the update over pubsub

This will minimise the viewer front end making requests to your EBS if your front end checks Twitch configuration service first.