RFC 0004 - Developer Rig

[davethecust]

Summary

Developing Twitch Extensions is currently a nontrivial process. Developers need to onboard, create their extension, set up their dev environment, design their extension, build their front end and back end, test it both locally and hosted, and then submit it for review. We are aware that significant friction exists in a number of these steps.

One of the ways we are addressing these issues, is by releasing an Extensions Developer Rig - a web app that runs locally on a developer’s machine. The Developer Rig is focused on simplifying and easing a variety of tasks during the extensions development lifecycle, including testing, getting started, and more. We believe this will enable developers to iterate more quickly and focus on building a great extension.

This RFC talks about Developer Rig V1. We are planning on regularly adding new features over the course of 2018.

Motivation

Per developer feedback, we’ve identified two particular areas of pain in the process. The first is testing an extension generally. The second is easily getting started.

With this in mind, V1 of the Developer Rig focuses on the following:

1. Provide developers with the toolset to locally test their extension across the multiple views and roles that they will need to support on Twitch.

2. Provide a strong starting foundation for developers by auto generating the necessary front end scaffolding for an extension

Detailed Design

Local Development

The initial version of the Rig is a lightweight web app that runs in the browser. We will enable extension developers to test extensions end-to-end locally, leveraging Node 6+ and React. The Rig will render extension clients in a variety of contexts and views - i.e. broadcaster, viewer, linked and unlinked users, logged out users. There will be multiple anchor types supported by the Rig at launch, including support for testing and rendering overlay, panels, and mobile extensions. The Rig will also render the broadcaster configuration and live configuration views.

For mobile extensions in particular, developers will be able to set the resolution of the view to account for the different device screen sizes.

The following are mocks of the Rig showing multiple views displaying various Overlay or Panel views. Developers will also be able to output logs to a “Rig Console” during testing. Each of the views is labeled with the type of “user” in it, i.e logged in viewer, broadcaster etc. Developers will not need to be stream to test overlays in the Rig.

While the extension is running in the Rig, developers can interact with it just like an end user.

Developers will have the ability to add additional views and roles from Rig itself or from the command line. For example, developers can test how multiple viewers will experience input, in a side by side view.

Getting Started Quickly

Developers will be able generate “hello world” type code from the command line to get up and running quickly. We will continue to add additional samples in the future that can be easily pulled up in the Developer Rig.

The Rig will work on Windows, Mac, and Linux.

Rollout Considerations

One of our tenets is to make the development process easier, but not restrictive. With that in mind, we do not intend to mandate that developers use our tools for their process. We are aware that other tools are available, and while we intend to provide a great first party experience, if other tools meet developer needs, we encourage their use.

We intend to continually update the Developer Rig with additional functionality and fixes.

Alternatives

Currently, the most common alternative is configuring an extension with a broadcaster whitelist and adding the developer’s twitch account to said whitelist. After that, submitting your extension and getting it into some testing state, either local or hosted. Then a developer must stream to their channel and test live on the Twitch Website. Then one is able to test their extension. Iteration time is significant with this workflow.

Other third parties have begun to build similar tools to support testing and scaffolding scenarios. While they come with a variety of trade offs, they are important contributors to the extensions development community.

[Seravy]

This sounds like a good plan to get newer developers on board. As someone who has overcome some of the hurdles already I would love to see some of the utility of this to be used for those who have their own environments set up. For example I would like to see broadcaster, viewers logged in and off, all on the same screen while it hits my own web server running on local host or hosted at twitch.

Another thing I have had trouble with is the ability to test account features I have not unlocked, such as subscribers, relying on the mercy of friendly streamers to test. An environment which will unlock all features and api calls would be very helpful.

Cheers

[Hellcat]

Picking up on Seravys suggestion on env environment with all features: maybe a add an API sandbox where we get all those features and the ability to trigger events like “new follower”, “new subscriber” and the likes. Would make testing way more easy.

[rbartlet]

All great ideas, and very much inline with our thoughts as well. As with any new initiative, functionality will be limited early on, but will be expanded over time. Locally mocked APIs is one such area that will continue to evolve over time.

[BlueCloudDev]

The setup and deployment process is definitely the piece of Extensions that killed my enthusiasm. Having a set boilerplate code sample that gets you right into the fire would lower the barrier for entry significantly. I’m not particularly fond of either React or Node but I know they are some of the most popular frameworks for non enterprise level projects, so I guess I’ll have to suck it up.

It seems like you’ve solved the majority of the problems with developing extensions. Given that these extensions are likely going to be personal projects, usability is key as no one wants to code after work on something as difficult as thier day job, or something difficult to pick up for beginners. Supporting a JS framework like React over just straight JS is also critical for much the same reason.

Beyond that I don’t think I can comment any further without getting to use the service.

[Ciberus]

Insane variant - create twitch extension cli tool
I hope u understand me regardless of a ton of grammatical errors, i’m not native english speaker.

TwichExt CLI - commands

– twitchext init “my-awesome-ext-name” (possible init steps below)

• Auth on twitch developer portal
• Select one of pre-created ext from dev dashboard
• Select available dev stack like Vanila JS vs TypeScript vs Flow, MobX vs Redux vs MobX-State-Tree
• Select linter TSLint vs ESLInt vs Null
• Auto create and init boilerplate with: webpack/gulp/* + babel + TypeScript/Flow + MobX/Redux/MobX-State-Tree + TSLint/ESLint + Jest

– twitchext rig (start local server with DevRig)
– twitchext deploy (build extension in zip and send it as new “In development” version ofc need to check if version already “Live” and so on, also here screenshots from pre-defined folder can be uploaded, after deploy log in console link on this version to continue preparation for hosted test also link on “channel for review”)

Troubles and how to avoid them

1. Supporting this amount of dev stack variations - suicide. Best way provide one boilerplate following best practices on dev stack like this for example: React + MobX + Babel + Flow + ESLint + Jest + WebPack(possible best practices list):
   – Babel plugin to remove console.* messages
   – Localization strings example
   – Auto-hide overlay with video player elements(after 5 sec)
   – On context change event reactions like theme changing/game/resolution/language
   – ESLint/TSLint rules following guidelines and policies
   – …
2. After deploy there is many things u need to change manualy in dev dashboard. Solution - create config twitchext.json
   Config example:

{
  "twitchext": {
    // Settings
    "name": "My awesome ext name",
    "summary": "My awesome ext so awesome Kappa",
    "author": "awesomeDev322",
    "oauthRedirectUri": "https://localhost/",
    "logo": "./images/awesomeIconOfAwesomeExt.png",
    "description": "Awesome description for awesome ext", 
    // Screenshots
    "screenshots": "./screenshots", // all screens from this path uploads on deploy
    // Version details
    "version": "0.1.0",
    "supportEmail": "awesome@awesomeservice.com",
    "EULAOrTermsOfServiceUrl": "",
    "privacyPolicyUrl": "",
    // Extension capabilities
    "requesIdentityLink": false,
    "requiredConfigurations": "awesome but required config info",
    "requiredBroadcastersAbilities": "",
    "whitelistedConfigUrls": "https://awesomedomain.io",
    "whitelistedPanelUrls": "https://alsoawesomedomain.io",
    // Asset Hosting
    "hosting": {
      "testingBaseURI": "https://localhost:8080", // if not defined use standard
      "viewerPath": "viewer.html", // if not defined use standard
      "configPath": "config.html",
      "liveConfigPath": "",
      "supportMobile": true // extension support mobile(only for panels)
    },
    // Access
    "broadcasterWhitelist": [ 46365073 ],
    "testingAccounts": [ 46365073,43665292,46365073 ],
    // Review details
    "nameOfChannelForReview": "https://www.twitch.tv/awesomeDev322",
    "walkthrougnGuide": "My awesome ext do awesome things and do it awesome what a twist LUL My awesome ext do awesome things and do it awesome what a twist LUL My awesome ext do awesome things and do it awesome what a twist LUL My awesome ext do awesome things and do it awesome what a twist LUL My awesome ext do awesome things and do it awesome what a twist LUL",
  }
}

3. Some tools require experience(like MobX/Flow/Jest) can be fixed in two ways:
   – 2 boilerplates: “pro” and “vanila”(for beginners)
   – Provide small description/intro for all tools

Summary

TwitchExt CLI + boilerplate on fixed dev stack following best practices + DevRig = Profit!?

[Metamancer]

Would love to also see support for multiple developers working on an app. I am a partnered broadcaster and absolutely do not want to be sharing my login information for access to the dev dashboard as it also gives access to everything else. Having multi-developer access would make things a lot easier when it comes to asset uploads and versioning as well.

[rbartlet]

Having a CLI tool, or at least a selection of scripts is already a when rather than if.

Support for role-based access management, and transfer of ownership for Extensions are a little beyond the initial scope for the rig. That being said, when (and not if), work on these areas begins, their functionality will be surfaced in the rig then.

[Jay_Kyburz]

You should provide an online sandbox, not ask developers to install this rig.

Asking developers to install the rig is the wrong direction, you should just provide a sandbox site that allows us to simply upload the HTML CSS and JavaScript required for the extension.

I think there are lots of good reasons.

1. It would be easier for me.

I have several other more important projects in development on my machine. I get worried about installing and making changes to my system that may impact other projects. (My node for example needed updating - who knows what other changes the install scripts made to my machine.)

I didn’t need to make any changes at all to my own machine to set up the backend using lambda and dynamoDB.

The rig is not even fully working on my machine yet, according to the readme I still need to set up some SSL stuff which will be some additional pain I should not have to suffer.

2. It would be easier for you.

You don’t need to support Mac and Windows and all the problems that come with that. You just need to get the site running somewhere once and clone one off for each dev after they complete the on boarding process.

You wouldn’t have to mess around with offline and online modes and mocs of the API, it could all be live and functioning as it should but on the sandbox rather than the live site.

Jay.

[JJ_The_Bunny]

Would seem a Docker setup might be a better option, could run locally without having Twitch stand up and/or manage a service.

[blakegreen]

cool thanks a lot