[RFC] Optional Rate Limiting

[trezy]

Authors	@trezy
To be reviewed by	31 October, 2020

Need

Rate limiting on Twitch can be a serious issue, and testing apps against fdgt can lead developers to believe that their bot won't encounter issues because it doesn't implement any form of rate limiting. Developers need some form of simulation for rate limiting so they can verify that their bot will still work on Twitch.

Approach

fdgt should implement optional rate limiting. The rate limiting mode would be toggled by sending a command to the chat (rate-limiting [on|off]) to simulate Twitch's rate limiting. This could also take some parameters to do things like force rate limiting immediately instead of simulating Twitch's rate limiting.

Benefits

In a real Twitch environment, an application can be "global'd" for misbehaving. This can result in developers being prevented from running their applications for substantial amounts of time. In fdgt, this misbehaving can be allowed safely (due to the sandboxed nature of connections), so there's no need to force developers to deal with rate limiting. Once they're ready, though, developers can opt-in to rate limiting, allowing them to test their applications against realistic Twitch rate limits and verifying that their applications won't be affected by rate limiting in a production environment.

Alternatives

Forced rate limiting

We could implement rate limiting on all connections all the time. The main drawback to this approach is that fdgt does not currently implement rate limiting, so this would be a breaking change requiring us to release a V2 of fdgt to avoid breaking backwards compatibility for developers that currently expect fdgt to work without rate limits.

Acknowledgements

Thanks to @BarryCarlyon and @Pykera for their contributions in the TwitchDev Discord.