The api-gateway helm chart is used to generate the deployment of the "old" api gateway (used for api.wikimedia.org) as well as the "new" REST gateway. The "old" api-gateway already has rate limiting support. We want to add rate limiting support for the "new" REST gateway.
Initially, the chart should support the following:
[x] rate limiting should be disabled per default
[x] rest routes should be able to opt into rate limiting
[] the user identity willx] rest routes should be taken from the centralauth-user cookieable to opt out of rate limiting
[] rate limiting should be applied only if a spcial header is sete by the client, providing the cuser "class" that determins the rate limitsx] the user identity will be taken from the centralauth-user cookie
[x] rate limiting should be applied only if a spcial header is sete by the client, providing the cuser "class" that determins the rate limits
[x] rate limiting is implemented using the same Redis backend that we also use to implement rate limiting for api.wikimedia.org
By the end of Q2, we want to support:
[] rate limiting should be enabled per default, but in shadow mode
[] rest routes should be able to opt out of rate limiting
[] rest routes should be able to chosse between shadow mode and enforcing limits
[] the user identity will be taken from a JWT provided in a header or cookie
[] the user class will be taken from a JWT provided in a header or cookie
[] support limits per minutes and per second at the same time (see T408132)
Eventually, we want to support:
[] rest routes should be able to chosse between shadow mode and enforcing limits (needs Envoy 1.33)
[] cost-based rate limiting based on upstream request duration (needs Envoy 1.33)
[] (maybe) decentralized (horizontally scalable) state using ring-hash load-balancing (needs Envoy 1.35)