Summary
On March 21, we released the Developer Rig to the open source community – it’s a tool designed to help developers more easily build and test their extensions using Twitch production APIs. We’re excited by the community’s response to the Developer Rig, and now we want to make it available to more folks (and make it more useful).
Our proposed contribution to the Developer Rig project focuses on the ability to create and run an extension that communicates with local resources and does not communicate with Twitch production APIs. With these changes, any developer, whether they have gone through Extension Developer Onboarding, can create, build, and test an extension in the Developer Rig. Developers can also construct a “run list” of different responses for end-to-end testing.
Motivation
We want to make it easier for developers to get started building extensions.
Today, to build and test an extension, developers must complete Extension Developer Onboarding, go to dev.twitch.tv to create their extension, find and pull several pieces of configuration from the dev site, and then use that information to load the Developer Rig.
Local mode will let a developer download the Developer Rig and get started immediately. There is no need to create an extension on the Twitch dev site while developing locally. When developers are ready to go through Extension Developer Onboarding, they can do so at their own pace.
Additionally, we recognize that developers need better capabilities to perform integration testing during extension development. We want to provide developers with the flexibility to hit mocked API endpoints with easily configured/modifiable responses.
Detailed Design
The Developer Rig will support two modes: local and online. The online experience will remain the same as today. Developers can launch the Developer Rig in either mode. In the near future, developers will be able to toggle between these modes from inside the Developer Rig.
The local experience mocks out the endpoints and helper callbacks used by their extension frontend and backend. From the command line, developers can control the responses to suit their needs.
Developers can configure a “run list” of responses, allowing them to test user journeys for their extensions. Initially, this configuration will need to be done via the command line/the files directly. As a follow up, we will enable developers to view their run list from within the Developer Rig, and later edit it.
The Developer Rig will provide a local PubSub implementation, that allows developers to send messages and listen to topics. At launch, we will not have rate/size limiting, so please be aware of this when you transition to using online PubSub. There will be no startup configuration requirements to run the Developer Rig in local mode.
In order to use the Developer Rig in local mode, a developer will need to ensure that the extension being loaded points to assets provided by the Developer Rig:
- The JavaScript helper library needs to be the version included with the Developer Rig
- The Extension Backend Service will need to point to the PubSub endpoint provided by the Developer Rig
Both of these will need to be updated before putting an extension into review.
Rollout Considerations
Local mode functionality will be incrementally added to the Developer Rig. Initial additions will focus on command line interactions, whilst subsequent work will provide a GUI-based experience.
Since local mode will be a separate way to launch the Rig at the outset, it will not affect the current online version the uses Twitch production APIs when it ships.
In the future, functionality currently provided on the Twitch dev site, will be incorporated into the Developer Rig, letting developers create local extensions, promote these extensions to Twitch, and move them to review, and eventually released. Local mode is a small step forward as a part of this larger block of work.
Alternatives
An alternative could be to implement Developer Rig specific code paths in production systems. This leads to harder to maintain spaghetti code which has a higher likelihood to end up broken with no one knowing why, which could negatively impact viewers and developers.