Personally I seed a users follow count once per day from the follows endpoint
Then use eventsub to keep up to date with new follows.
Not really, given your name I’m assuming you are keeping stats.
So now you load user once per day to monitor for name changes (or use the user change eventsub)
And then hammer the follows endpoint for follow count update or seed it once per day with the count and use eventsub to count follows up.
Or just don’t bother counting follows since it’s not much of a useful metric generally speaking.
It’s also worth considering that Twitch doesn’t want to support this sort of external stat gathering.
It’s possible to consider that follows is an item of PII that might be protected via GDPR and other privary laws, and if you are collecting users follower counts without permission you might be in violation of these laws.
And if you do have permission then the eventsub topics for the users you have permission to collect are “free”/zero cost. And don’t count to your limit.
100 calls to follows is 100 calls to 1 database table.
1 call to users for 100 users in one go (if it contained follow count), is 100 database table joins and then spit back the response. And if the only data you are after is the follow count then it’s all burnt.
Depending on how this is architectured internally at Twitch it might not be that at all and it’s buried in multiple services. (Which might be the case when we consider Twitch is working on anti follow bot measures, or external Services such as Root’s Followbot Removal tool essentially DDoS Twitch Daily with follow removals)
Thus requiring extra cycly times to get data when joining two data types.
That is likely why Twitch doesn’t have follows on the users endpoint as it allows doing 100 users at once on the uses endpoint.
TLDR: I really don’t think we will see the follow count on the new users endpoint. Since the new users endpoint allows 100 users at once.
We’d be more likely to see a GQL type solution. And we all know what a mess that seems to be