Is it on the cards for this to exist at some point? Now that EventSub is available, and users/follows supports App Access Tokens, the only problem-child I have is fetching subscriber counts for a User who has authorized my App before. For example, helix/subscriptions?broadcaster_id=123
There has been no announced plans for changing the way OAuth tokens are required in Helix. EventSub is its own service that’s separate from Helix so is not an indicator that other teams on Twitch may change the existing ways of doing things.
If a user has previously authorized your app, you should store their User Access Token and Refresh Token if you plan to use Helix endpoints that require that authorization.
There has been no announced plans for changing the way OAuth tokens are required in Helix.
Ah, that’s a shame - thank you for the prompt reply!
If a user has previously authorized your app, you should store their User Access Token and Refresh Token if you plan to use Helix endpoints that require that authorization.
I do - however I have to process in a serverless environment, which is why EventSub and App Tokens in general were really just a hugely beneficial thing for me (As to not have to spend extra time fetching their token, decrypting it, running the request, refreshing the token if it failed, rerunning the request, storing new refresh token if needed, and so on)
Even in a serverless environment it can be beneficial to still store your tokens in a db that your apps need to fetch from when run if you ever want your app to scale.
There’s a maximum number of 25 app access tokens, after which when you create more it’ll kill the first ones, so in a serverless app if there’s any concurrency it can’t scale beyond 25 instances, where as if for example you’re use AWS Lambda for your serverless apps, you can simply pull the token from a DynamoDB table which will have minimal delay and allow the serverless process to grow in concurrency/complexity.
Even in a serverless environment it can be beneficial to still store your tokens in a db that your apps need to fetch from when run if you ever want your app to scale.
Yup, doing that for other areas of my ecosystem, it’s just much easier to use an App Token instead of pulling potentially thousands of access tokens from the DB and running the logic I mentioned against all of them
There’s a maximum number of 25 app access tokens, after which when you create more it’ll kill the first ones, so in a serverless app if there’s any concurrency it can’t scale beyond 25 instances, where as if for example you’re use AWS Lambda for your serverless apps, you can simply pull the token from a DynamoDB table which will have minimal delay and allow the serverless process to grow in concurrency/complexity.
I’m aware RE: there being a limit for App Access Tokens, I have a central authority to maintain a single one - and in my case, I store encrypted User Access Tokens in RDS (Since the user-facing side of the ecosystem requires it), so pulling them is not nearly as performant as I’d like (Referring to previous logic)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.