Can’t make heads or tails of extension development with the current documentation and am wondering if anyone has spotted a video demonstration of basic extension development using the dev-rig?
EDIT: More specifically, using the twitchdev/extensions-hello-world template, from local test with dev-rig to final deployment, hosted backend included.
You could develop an extension entirely without the rig.
You could build something that uses no Twitch Features and thus no need to touch anything from the Twitch JS extension helper, which is what the Rig simulates.
So, we should start at the beginning.
A Twitch Extension is, basically, an iFrame.
That iFrame loads a website consisting of HTML, JS and CSS, (and perhaps some other things)
So, if you can build a website, then you can build a Twitch Extension.
Anything else on top of that is to do with Twitch Interactivity, as provided by the helper. Or something EBS/backend servery, which isn’t simulated in the rig anyway.
So the question is, rather than pointing you to a video about the rig, what are you stuck with?
I started with the dev-rig, using the extensions-hello-world template.
function createRequest(type, method) {
return {
type: type,
// url: location.protocol + '//localhost:3600/color/' + method,
url: location.protocol + '//alexr.ca/srv/gr_hello/color/' + method,
success: updateBlock,
error: logError
}
}
// The developer rig uses self-signed certificates. Node doesn't accept
// them by default. Do not use this in production.
// process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';
...
const serverOptions = {
host: 'localhost',
port: 3600,
routes: {
cors: {
origin: ['*'],
},
},
};
$ node bin/generate.js server
...
Please install and trust cert at conf/server.crt
Note: not sure if previous line is relevant for a secure (openssl+certbot) nginx-fronted web host. I’ll look into this, next
upstream gr_hello_backend {
server 127.0.0.1:3600;
keepalive 32;
}
...
location /srv/gr_hello {
# service base URL will be https://alexr.ca/srv/gr_hello/
proxy_pass http://gr_hello_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
access_log /var/www/logs/gr_hello.access.log;
error_log /var/www/logs/gr_hello.error.log;
}
$ node services/backend.js -c <twitch dev provided extension clientId>
-s <twitch dev provided extension secret> -o <my owner id>
Back on rig…
Access to XMLHttpRequest at 'https://client-event-reporter.twitch.tv/v1/stats'
from origin 'https://localhost.rig.twitch.tv:3000' has been blocked by CORS
policy: Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested
resource.
https://alexr.ca/srv/gr_hello/color/query 502 (Bad Gateway)
Suspecting rig certs issues, I will now bypass said rig and serve the front-end via some other setup (node serve), then will look into cert trusting.
The documentation and the rig could be improved. Several things are not explained very well (example: what are the implications of checking the “I am using the dev-rig” option when one creates an extension via the Twitch Dev Site for later deployment stages), which makes progress difficult.
Am now by-passing the rig, serving the front-end of twitchdev/extensions-hello-world w. help of a node server.
Loading public/panel.html, the UI appears but the button is never enabled because neither onContext nor onAuthorized are getting invoked, despite presence of the helper:
panel.html:
<body>
<div id="app" class="full-height"></div>
<script src="https://extension-files.twitch.tv/helper/v1/twitch-ext.min.js"></script>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"
integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
crossorigin="anonymous"></script>
<script src="viewer.js" type="text/javascript"></script>
...
viewer.js:
...
twitch.onContext(function(context) {
console.log("onContext");
//twitch.rig.log(context);
});
twitch.onAuthorized(function(auth) {
console.log("onAuthorized");
// save our credentials
token = auth.token;
tuid = auth.userId;
// enable the button
$('#cycle').removeAttr('disabled');
setAuth(token);
$.ajax(requests.get);
});
...
Time to re-read the docs. 
Your server is down/throwing a 502. Check your server error log.
The other console log error is irrelevant. Just the stats reporter failing
Check chrome inspector, but the network tab for 404’s. I bet your viewer.js is not being loaded at all…
I am indeed getting a web server error:
upstream prematurely closed connection while reading response header from upstream
More specifically:
2018/12/14 12:13:34 [error] 18544#0: *41 upstream prematurely closed connection while
reading response header from upstream, client: 104.163.163.175, server: alexr.ca,
request: "GET /srv/gr_hello/color/query HTTP/1.1",
upstream: "http://127.0.0.1:3600/srv/gr_hello/color/query", host: "alexr.ca"
which might imply a backend.js timeout of some sort (authentication issue perhaps)…
Meanwhile, back at the rig…
Access to XMLHttpRequest at 'https://alexr.ca/srv/gr_hello/color/query' from
origin 'https://localhost.rig.twitch.tv:8080' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested resource.
EDIT: After porting the Hapi server based example to a simple node express setup,
requests are no longer blocked. I am able to query the current color.
EDIT 2: The color cycling post request times out and the server returns a 403.
EDIT 3: Fixed by increasing the token expiry time.
You need to configure the CORS policy on your EBS.
It’s not a dev rig issue it’s a issue with your EBS/backend server
Not a dev-rig issue, but rather something to do with the extensions-hello-world backend.js part. I replaced the Hapi, CORS-enabled (apparently) server with an express, CORS-enabled server, and it worked. I could have configured my nginx location block to do the same but that would have been a hack, a workaround, since the original (Hapi) solution doesn’t work as presented (CORS-enabled).
You only provided information indicating you were using Nginx.
Either way, backend EBS stuff can be a bit fiddly at times and generally spreaking the hello world example expects everything to be locally run off the rig. So doesn’t really have a CORS issue (and/or CORS is configured to allow the local host URL since CORS headers supporting naming domains)