API Sandbox Discussion

@DallasNChains directed the discussion to the forums from here: https://github.com/justintv/Twitch-API/issues/344#issuecomment-231258510

So let’s talk about a Twitch API sandbox.

Goal: Give developers the ability to get sample data from the Twitch API so that development apps can be cleanly tested.

Specific areas include:

  • Partnered features, where you can’t get real data without an OAuth token from actual partners
  • Risky features (PUT/DELETE) that if done incorrectly can ruin a persons hard work
  • General development (GET/POST) can have repeatable, testable results so that you can make sure X input = Y output. This is particularly relevant for endpoints like /Stream where a person could exist and disappear between any given API call.

Sandboxes are an important piece of API development. They provide a safe ground for developers to test and experiment with new things without putting a live users data at risk for unintentional changes and data leaks. They allow for measuring and profiling in a safer environment than production, so you can see if a request is misbehaving - and it allows Twitch to see what people are experimenting with, allowing (in most cases) enough time to prepare production servers for new developments, or potentially coordinated releases for cool new features.

Currently there is no access to partner data for third party developers who do not have direct access to a partners OAuth key. While it’s fairly frequent for developers to make those contacts with streamers to get a key, it would be nice to be able to approach partners with an actual product instead of an idea. It’s a lot easier to say ‘I have this awesome piece of software, here’s how it could be used on your channel’ than ‘I have this awesome idea for some software, I haven’t designed or programmed it, but share your sensitive OAuth tokens with me and I can give it to you!’

Another benefit of using a sandbox for twitch would be storing a static snapshot of data for each of the endpoints, only having to update it if the API endpoints change in the response returned. Static data can be anonymized so as to not indicate any particular channel since the sandbox only needs to mimic the correct types/data sizes, rather than ‘real’ data. (There should be consistency in the anonymization though, a user id that is returned in /streams should match a user id that is returned from /channel)

In addition to the benefit of not developing against live data from twitch (which sometimes has a side effect from PUT/DELETE), it would allow more developers to work on partner features without having to actually involve a partners oauth token. (Think a generic third party being hired to develop tools for the broadcaster, but not have to give that third party actual access to your subscribers and sensitive data like stream keys)

6 Likes

Could not agree more. Not having access to data returned by “live” events (i.e., follows, subscriptions) has forced me to test code dozens of times using live data, meaning that the streamer was actively streaming as I was making changes to the requested product. As is common in software development, problems and errors arose. And viewers saw them. Being able to emulate live events (or even storing a static snapshot of live data, as suggested) would be a godsend. Such a sandbox environment would encapsulate the development cycle completely and promote the happiness and health of developers and users alike.

Thanks for creating this thread and the thoughtful ideas! I’ve been talking about this internally since I started. :slight_smile: Keep the discussion going!

bump

I sent this around internally as a good set of reasons that we should prioritize a sandbox. Hopefully they’ll listen to us. :wink:

As always, I’ll keep you posted. Thank you for the great ideas!

Bump.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.