Trouble understanding the EBS

I’m thinking of getting into Twitch extension development and so I’ve been reading through the documentation and other resources trying to understand it and see if I would be able to do it.

However, I’m having some trouble wrapping my head around the EBS. I understand its role and how it’s supposed to work, but I’m not sure exactly where I’m supposed to put it. Keep in mind I’m not a web developer, so go easy on me. :sweat_smile:

In all the examples I’ve seen, it seems like localhost is used to host all assets, which is supposed to be for Local Test state, but what happens when I move to Hosted Test and then to release? The documentation says to change the redirect URI to the EBS, but how do I get that? Localhost is obviously not a viable option. The documentation also says to upload only the front-end assets to the Twitch CDN, but that can’t be viable as a redirect URI either since I wouldn’t know what it is. Do I need to purchase the use of the web host? Can I simply host my code on GitHub to use?

I’m also trying to figure out what it would take to connect/authorize a user through Streamlabs to get access to their API, and they also require a redirect URI. This would be the same URI that I use in the Twitch extension URI in the extension settings (i.e. EBS URI), correct?

I’m not seeing any answers to this specific confusion I’m having so I’m guessing I’m just confusing myself, and the answer is trivial. Any push in the right direction is appreciated!

you’ll need to get hosting, and the url to your hosting has to support ssl (https://). Learn the code flows for authentication for oauth, because its important to understanding how to connect to both twitch AND streamlabs in an authenticated state. But basically once you go through the flow in streamlabs, that info is posted to your ebs to use. in most cases you won’t need to follow oauth for twitch extensions, because validating the jwt should be your way of authenticating a user.

Thank you for the response.

So it looks like I can just upload code to a repo on GitHub and reference it using the<user>/<repo>/<branch>/<file> URI. Is that viable, or is using GitHub a big no-no here? Or, better yet, what would you recommend and/or see other people using?

EBS is just your own server. You can’t run a server off github files. You have to get a domain name, find a hosting service, and go thru that whole process.

fireeye :
basically the easiest way to get an EBS is to build an api and host it somewhere.

so all the technology related to the topics “restful api with insert-your-favorite-toolchain” apply to this.

your extension is usually just some frontend code consuming your APIs endpoints.

you can also technically build an extension entirely without an EBS, but obviously this is useless for some usage scenarios.

1 Like

Thank you for the useful reply.

I have heard of RESTful API before, but do not know much about it so I’ll have to go learn more.

Expanding on that thought though, it seems like it is completely possible for someone to write an EBS and make it public for other extension devs to use. This would be useful since a lot of the calls to and responses from the Twitch API are about the same. But I don’t think it would be a smart thing to use something like that since I’d be sending my client ID and secret through someone else’s API.

With that in mind with my own EBS, would it be smart to supply my front end with a special ‘secret’ that my EBS would then need to verify before being used so that someone else doesn’t get access to it?

yes that would be a good idea and that’s basically what twitch’s extension helper is doing for you already:

it supplies the extension iframe with a jwt which is signed by twitch using a secret shared between you(the developer) and twitch.
you can then use this jwt for backend calls to your EBS, making sure no thirdparty/non-legitimate will be answered by your EBS.

this is also explained in the extension docs :slight_smile:

1 Like

Ah yes I do remember reading that now that you mention it. I kind of glossed over that at first because I was still so confused about my earlier concerns.

Thanks a ton! :grinning:

I may be a little biased, but my suggestion for where / how to host your EBS would be to use AWS Lambda. It is the perfect fit for the nature of the traffic you will see in your Twitch Extension.

Take a look at the docs here:

Feel free to follow-up or start another thread w/ any questions!



Cool, thanks for the suggestion!

Using AWS Lambda is exactly what we’re doing for the Hearthstone Deck Tracker Extension. You can find our EBS source code here if you’d like to check it out for reference.

We’ve had a good experience with it for our EBS so far, but there’s a few smaller caveats to be aware of, such as keeping the lambda warm (we use Zappa’s keep_warm that basically cron’s it every 4 minutes).

1 Like

Wow, I just spent two days trying to write by EBS in node because their boilerplate included an EBS and I had always assumed that if I uploaded it with the rest of the front end, it would also be built and hosted based on the docker file that’s included in the boilerplate.

Their documentation needs to make this more clear, especially in the boilerplate itself.

1 Like

I run my EBS with node/express and Heroku. works great and Heroku is super easy to use.

Some of the continued feedback that has been received (and heard), is that it is difficult for people new to developing Extensions to understand what an EBS is and how to go about building one. There is work underway to provide best practise examples, and additional services to alleviate the need for an EBS in the first place.

This is so true! It took me also a lot of time to realize how the EBS works since I was also caught up in the same confusion!:speak_no_evil::crazy_face:

It looks like their new documentation with samples they released make it clear in its own line in the documentation with italics.

Hold up. Can you get more specific?

On our roadmap, there is a configuration service… Beyond this there are more services planned, that provide functionality common to many EBSs today. More details will come in time.

We want to make it easier to build Extensions.

1 Like