Once Helix is in more of an... acceptable state (e.g. I still need subscriptions data), conversion to Helix should at the very least start. Luckily Helix allows us to get rid of a few things, but also requires to changes to other things.
Some endpoints (V3/V5) will eventually fail too, because of their removal at the end of 2018. Either some alternatives have to be implemented, or just straight up removed with an error message (though I'd like to avoid the latter, if feasible somehow).
Other things to take into consideration:
- Most endpoints seem to support a form of
user_login (username) parameter, which should make the cached_twitch_users database table unnecessary (as I would no longer need to convert usernames to IDs before sending the request). The implementation for this was garbage in the first place, so that's just an improvement overall.
- All channels (users) will need to re-authenticate for the subcount/points endpoints. The thing here though is that it will require both a V3/5 scope + a Helix scope. It might look weird on the authentication page, but considering the Helix scope for subscriptions isn't available yet, it's hard to tell.
- This would be a good time to also refactor a lot of the code. I'm not happy with the current implementation of the API calls, and the format of the current Twitch API code is also not really... the way people would usually do it, I guess. Something should be done, though I haven't figured out what exactly I want to do.
- Re-consider rate-limits, maybe? Luckily DecAPI has gotten a higher rate-limit (woohoo!) on Helix, which means that I can maybe consider bumping up the rate-limit. With that said, not many users should ever hit that rate-limit and I've not seen many "legitimate" users do so, which means that this probably isn't necessary at all.
I'll update this list with more stuff once I have them all in my mind.
Once Helix is in more of an... acceptable state (e.g. I still need subscriptions data), conversion to Helix should at the very least start. Luckily Helix allows us to get rid of a few things, but also requires to changes to other things.
Some endpoints (V3/V5) will eventually fail too, because of their removal at the end of 2018. Either some alternatives have to be implemented, or just straight up removed with an error message (though I'd like to avoid the latter, if feasible somehow).
Other things to take into consideration:
user_login(username) parameter, which should make thecached_twitch_usersdatabase table unnecessary (as I would no longer need to convert usernames to IDs before sending the request). The implementation for this was garbage in the first place, so that's just an improvement overall.I'll update this list with more stuff once I have them all in my mind.