I was sent here by one of your employees who’s discussing the partnership with our eSports platform, as he didn’t have the required API knowledge.
We’re currently implementing a feature on our platform where you link your Twitch account and, when you’re live, a story is automatically posted on your profile, linking to your Twitch channel. A message in our tournament chat will also be posted, notifying the other participants of your stream.
Our current version is using the PubSub API, but we’re subscribing to the video-playback topic. This isn’t officially documented in your docs, but it is on your Github. So we’re wondering if this is already allowed to be used by a third party?
If it is, I think we’ll also be needing an increase in our allowed connections. Docs state that there’s a maximum of 50 subscriptions per connection. But seeing as we have more than 11.000 registered users, we’ll reach this threshold quite fast.
If needed, you can always contact me at firstname.lastname@example.org if you need further details about our collaboration with Twitch.
The github has some notes (in error) and a PR request that someone added of his gathered notes, but it’s not in the dev.twitch.tv documentation because it’s not supported for use by third parties and can and will change at any time, or just not work™.
With 11k users theres probably a better way than using pubsub to determine live status, but I’m not doing your work for you…
Not supported? It’s actually already working in our development environment. I’m just wondering if we’re allowed to use it in production.
And I don’t really see what could be better than using pubsub. We don’t want to periodically query the Twitch API, because that puts unnecessary strain on our servers. Our whole platform is already working with sockets, as the whole app is realtime.
If it ain’t documented it ain’t supported, that means if and when it breaks you can’t complain about it. I myself use this topic, but I have two other backup methods for when the topic fails, and it fails a fair bit.
Which means you could use it in production but when it breaks, you need to have a backup.
You probably shouldn’t use it in production, because, Twitch wouldn’t grant you a elevated rate for an “unofficial”/unsupported API. You need to check 11k users? Using an unsupported API on a thing with a limited connection/subscription count?
A presence system broadcasting a user’s online status to all their friends.
And for your suggestion on using the current API: I’m really not inclined to make a call every minute to the API to see if our users came online. We have a full-fledged realtime web app that has over 500 concurrent users on a typical weekday, so it’s not just a simple PHP website that has a few pageviews per hour and can query the API whenever a page is requested.
We are in contact with Twitch for a partnership, but our contact person said this was the best place to ask API specific questions.
Barry is correct in all of his assessment. The video-playback PubSub topic isn’t a supported topic at this time. If it becomes a supported topic, the documentation will be updated to reflect that. The supported way to poll for liveness is to use the streams endpoint. If you have more questions, please let me know!
But then what do you suggest as my ideal approach?
If, for example, we have 500 users who have linked their Twitch account, do you expect us to call the streams endpoint 500 times per minute? But what about users who linked their Twitch but rarely steam? Why should we call the endpoint for them? And what if it’s nighttime in our region, why should we still poll the endpoint every minute?
The pubsub was the perfect solution for us, but this doesn’t seem an option anymore?
The approach to this problem is the same as other integrations that show live status. In short: poll the streams API, cache the responses, request stream info from your cache for subsequent users, and then refresh cache every 3 - 5 minutes. Our API endpoints are cached for at least 1 - 3 minutes anyway, so it doesn’t make sense to poll constantly for this information.
Well, that’s a shame really. We have a live chat room during our tournaments, via where we would automatically announce if a player started streaming. A delay of 3 minutes really gives a very poor user experience…
Not really, all streamers have the same “notification delay”, and as such a lot of streamers start their stream with an intro of some description in order for some time to pass in order to allow all the notifications to go out, including but not limited to email, mobile push notification and curse.
Gotta actually give time for people to actually turn up and login, in reaction to a going live notification.
Note that the /kraken/streamsendpoint has a channel parameter that allows you to request a comma-separated list of channels (ids on v5) to get the stream object for. I think the max is 100 per request, although I’m not sure if too long URLs could cause issues at some point. But either way, it doesn’t have to be 500 requests for 500 users.
I feel your pain on the constant endpoint calling… I have a Discord bot that polls the /streams endpoint periodically to announce live streams in discord… and it seems that having it run the checks with 2 minutes between the calls has been rather efficient (and the bot tracks over 4.5k unique channels, 500 unique games)… the announcements typically are sent to the appropriate channels within 3-5 minutes of the streamer going live, and I feel that’s a relatively fair delay…
and if your site is on LAMP, you could easily enough set a CRON task and never have to worry about it again (unless the API changes from v5)… you can call up to 100 channels per request and the guideline is 1 request per second… so for 11000 channels, what is that, a hair less than 2 minutes to make all the calls… that does not seem unreasonable at all