We recently noticed that the Get Users endpoint (https://dev.twitch.tv/docs/api/reference/#get-users ) does not have the total follower count. This endpoint is more or less the equivalent of the Channels endpoint in v5, so it is weird that this has been changed.
This is generally problematic due to the fact that you are now required to make multiple API calls to replicate one call to the equiavlent API call in the previous API.
Has anyone heard why they removed this data point? If so, has anyone heard anything about an update to that endpoint.
Yeah. This just seems like a weird choice on their part, since this is sorta a bedrock of most people’s use-cases for the API and it will require more API calls at the end of the day.
Hey @geardrops! Thanks for responding. Hope things are going well on your end since we chatted at TwitchCon.
The challenge there is a developer doubles their API calls if they need to update a user’s follower count to display it or perform some logic based on the follower count. At scale (and/or potentially if you need to do this multiple times a day), this becomes an issue in a variety of scenarios (especially now that measured rate limits are being put into place).
I’d love to know if you see this changing in the future at all, or if we should plan on this way for the longterm. @BarryCarlyon brings up the key point: is this an internal refactor away from appearing again, or is this low on the priority list?
I want to say that on our team, we all appreciate all your hard work @geardrops. We are all working hard to get moved over to Helix but several things like this really make this shift arduous, time-consuming, and ultimately expensive for our businesses (as the shift competes with our time spent on new features, fixing other bugs, etc.)
Really appreciate your information and/or help to understand more here if you can.
Ah yes, I understand your pain point. It would be easier to batch 100 users to update follow counts, than to have to call one at a time. We are trying to balance keeping the user call efficient and accurate with these sorts of pain points. The hope was that at least with Webhooks you could keep the follower counts updated that way, only having to periodically check the user follows endpoint to address unfollows.
However, if this workflow isn’t working for you all, then obviously we need to see if there is a way we can make things better. I’m not sure if there is, but I won’t know until I try!
Thanks everyone. We really appreciate your thoughtful feedback and your patience as we work to build an API that serves your needs.
Thanks for looking into this @geardrops, for those of us that do any soft of analytics work being able to bulk get follower counts is pretty vital. Is the performance issue specific to it being in the user request or is it more of a general issue with calculating the count?
Adding my voice to this and keeping the topic alive as this is indeed a basic requirement for the API. I mean the followers count is the very first KPI for a channel, so as soon as you’re doing analytics on a large scale it’s a pain to do it without a batch call (and becomes just impossible with API quotas applied).
Aren’t you guys keeping a “static” count of the followers in the users infos that you update every time there is a new follower?
Also you’re saying this is for performance reasons, but if you don’t put it in the user endpoint, we’re all gonna have to call the “users follows” endpoint 100 times more anyway (which, besides, is heavier at least data-size wise), so doesn’t look like you’re gonna get any performance gain from that
If you don’t want to decrease performance for calls to the users endpoint that are not interested in followers count, could you consider the solution of adding an optional “with_followers_count=1” parameter for those of us who will have to get that one way or another anyway?
This seems to be a win-win: calls to the API are divided by 100 (for you, and for us), and you don’t decrease performance for the “default” users endpoint ; so it’s a 100% positive impact for the API performance.
