Hello everyone!
I’m working on a serverless alert system in Javascript with Websocket. Unfortunately, I couldn’t find a way to get Follow events in real time without using Webhook (which requires a server).
Do you know if there is another method than checking manually?
Ideally, Follow events should be integrated into PubSub, but I haven’t found any info on the intention to add it.
Currently it’s only Webhooks or long polling the API.
Developer suggestions/requests can be posted to the Uservoice
https://twitch.uservoice.com/forums/310213-developers
You probably should be using a server, as you can then manage your user oAuth keys and secrets better
Webhooks rely on the underlying Helix API. So if you can’t use webhooks, just poll the API and track new followers yourself.
Also for an alerts system, I’d also high recommend a server so you can properly cache and de-dupe followers, otherwise if you’re just doing this all client-side (which is what I assume you are intended to do when you mention serverless, rather than serverless technologies such as AWS API Gateway/Lambda which would work perfectly fine with webhooks) you could easily get spammed by someone following/unfollowing, and it’s not always viable to maintain a proper cache to prevent that when it’s done client-side.
Currently my system does not use a secret key and stores the token locally with the Web Storage API.
You need a secret to get a refreshable token, unless you provide somewhere a server to go get a token for users to copy/paste, ignoring the use of implicit auth where the token expires after a set time (and is not refreshable) and makes it “fun” if you/broadcaster are throwing your output in a OBS browser source, as apposed to window capture, for broadcasters to interact with when they need to reauth.
Yes your solution will work, but being client side, you are making it not as user/broadcaster friendly as it could be.
My original idea is to be able to auto-host the alert system in order to have a better control and a better reactivity. I didn’t think about spam but it doesn’t seem too difficult to compensate it by storing the followers during a session.
Indeed, with each use the user must pass again by a connection but as it already accepted the client_id the acquisition of the token is “relatively” transparent for him.
I’d imagine by that point, the Twitch cookie might have died and the caster opens up the stream, goes live and now they have a twitch login screen all over their OBS.
With the Web Storage API using localStorage, there is no expiration time (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage).
You “just” have to request a new one at the beginning of a live session.
You misunderstand,
You can create an implict auth token which’ll last for around 60 days
Or a regular user auth token, which’ll last 4 hours
User auth, is refreshable, implict auth you have to go round the loop
When you go round the loop you redirect a user To Twitch.
And the Twitch login cookie may have died or rendered invalid, which’ll mean the user is presented with the Twitch login screen instead of it just transparently making a new token.
LocalStorage lasting forever is irrelevant when compared to Twitch’s own Cookies/session.
hm yes, it’s a case I didn’t think of… but it’s a possible problem also for a system with a server?
With a server you don’t need to do the implicit oAuth redirect to Twitch, as you’d be using regular user oAuth and you’ll have a refresh token to use.
And if the regular user token cannot be refreshed via it’s refresh token, the broadcaster can do the reauthing “off stream” without having to right click the source in OBS and selecting “interact” and doing it visibly on stream.
And usually the token cannot be refreshed when the broadcaster has changed their twitch password or removed the app link for some reason, and since it’s done in the normal browser, the Twitch cookies/session should still be valid due to natural use of the Twitch website, unless the browser source where theres no natural website usage.
And using a server if the relogin to Twitch is required (which it shouldn’t if the streamer has logged in to go update their channel title etc, the caster won’t leak the length of their password and/or when the login to your tool you can present news/updates if needed, some of which probably don’t want to be visible on stream and/or provide the control panel.
I kinda rambled a bit there.
I think I can see the problem…
If I can separate the connection and the alert display then that would minimize the problem. I’ll have to think about that… Thanks!
Indeed.
It would also mean, in the case of follows, you can utilize webhooks, which for follows, would only need a app access token (no user ID), which you can make at will, and the user just needs to provide the twitch username/password, (no auth), course if you are adding subscriber events you’ll need a user token.
Then you just need a way for the frontend/alert display to connect to your server for the feed of events.
And having a “real” server or AWS serverless, you can persist a follow cache for as long as you see fit server side, without relying on local store (streamer updates OBS, which might dump localstorage or other $things affecting localstorage as OBS browser source is seperate chromium instance to the main browser on the computer), and the user decides “I’m gonna try xsplit today” or “I’m using a new PC” or “streaming from my friends/conference place” etc
Before switching to a server-based solution, I’ll still try to go through with no server… Just for fun 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.