We learned about this proposal today from @jbulava during the Twitch Dev Stream. We are fairly new to the Twitch development community, but already developed some open-source Twitch projects which put us in a position to comment on this proposal. At least so we think … 
tldr
- Mocks are hard to build and maintain.
- If you end up building a mock, use existing solutions like Postman.
- Developers ask for a mock, but they might be better served by Twitch maintained & tested client libraries.
Keep reading if you’re interested in learning more about our thinking.
Developers would like to test against the Twitch API without requiring affiliate/partner accounts.
Oh yes. We are still 8 followers away from affiliate level, which prevents us from fully testing our Golang PubSub library. Unfortunately the PubSub docs appear to be outdated, which doesn’t help either. Dkamps18 created a ticket for it.
[The mock] can be run offline/disconnected from the broader web, allowing users to develop on limited internet connections or used in CI/CD tooling.
Limited internet connections can be found on trains in Germany (German expat here). We’d recommend enjoying the train ride instead of trying to work though if you ever find yourself on a German train. Look at the 
at 1:35!! We can’t speak for other - maybe less developed - places, but if every Twitch developer is also a Twitch streamer or broadcaster, slow internet is going to be a big problem in the first place. Does the mock really need to address this problem?
Our bet is that most Twitch developers use readily available CI tools like Github Actions. Github Actions allow egress connections. We’d love to find out, but even game studios like Blizzard will most likely not block egress traffic in their internal CI tooling. We could see a world where Coinbase or other financial or healthcare institutions firewall away their CI suite, but are they really a user-story for this mock?
The point is, from our perspective “not having a (slow) internet connection” doesn’t appear to be a good product requirement.
[The mock] allows us to keep it simple and give an individual a sandbox to operate in without requiring shared resources.
Mocks are hard to build and even harder to maintain, especially if you’re also planning on implementing pseudo-logic to create “fake users, subscriptions, …”. You will be implementing a mini version of your production API! Even if you start with a small feature set today, think about the future feature requests flying in, asking for more pseudo-logic to test against. Based on your comments, you are already anticipating a drift between the mock and the production API. If the mock returns responses inconsistent from the production API, developers will lose trust in the mock and instantaneously resort back to the production API for testing. That’s what we would do.
So, if you really, really have to build a mock, we’d recommend looking into tools that allow mocking of APIs. Postman is a good example. People have mixed feelings about Postman and suggest alternatives. VCR is something we used in the past. There are many ports to other languages, including Golang. Heck, you could even roll your own reverse proxy to mock things out. Why reverse proxy? That’s how most of these solutions work. They record a real production API response and let you replay it for testing purposes.
With all that said, we think the root problem is something else. After a sharp analysis on our end (jk, we just looked at what libraries exist today - work in progress), we found many client libraries across all programming languages implement the same thing. This takes away from our developer experience, because we always have to make an educated guess which library actually works. The fast way is to trust the GitHub stargazer count. The only correct and slow way is to review the code. Reviewing code takes practice and experience with the Twitch APIs, something a new developer lacks. A dilemma.
We’d love to make a counter-proposal:
-
Twitch should build and maintain official client libraries for the most popular programming languages. Twitch engineers can test against the real production API if necessary, also having a deep understanding of how things work behind the scenes. This should make the mock obsolete.
-
Twitch should offer a sandbox environment for API calls [1] that have (expensive) side effects, i.e. for subscriptions, channel points, and so on. It would be accessible to all developers, regardless of their status (affiliate/partner). The sandbox environment could also be described as a “Twitch playground” where a developer can trigger certain actions from within the developer console. Think “trigger test webhook with this payload”. In fact we love the playground idea so much, we thought about building it ourselves.
-
Twitch should provide up to date documentation. It’s so important for newbies and should include guides, code examples and an API reference. The reference is necessary, because after all it is impossible to have client libraries for all programming languages, see [2] and [3].
To summarize: We’d love to see official client libraries instead of a mock. A sandbox environment would be helpful for integration testing. Good docs with tutorials and guides would be great.
We hope our feedback was helpful and we very much appreciate all of the hard work that goes into building Twitch and its community.
Tracy and Matt
PS: A mock for Chatbots/ IRC exists here: GitHub - fdgt-apis/api: `fdgt` is a mock API for the Twitch. Via `fdgt`, you can simulate events without having to spend a penny!
[1] Think Stripe Sandbox vs Production Mode, which can be toggled in their dashboard.
[2] There are ways to auto-generate client libraries from “templates”. Swagger might be a good tool to research. GRPC will take you to the next level, but can’t be retrofitted easily. Google has great success auto-generating their client libs. Have a look at their GitHub repo for example. The auto-generated libs provide low-level API access, handling API requests/responses in a generic way. Google then offers “hand-written” wrappers around the auto-generated libs for ease-of-use. [We just realized we should’ve used AWS examples ]
[3] Google offers Emulators. It’s not a mock though. Emulators tend to be helpful for integration testing and local development.