What does "public beta" mean? What guarantees does Stellate make?
Rate limiting for GraphQL is not a trivial topic. While opening up our solution to a larger audience, we expect to discover some special use-cases that won't work as intended. However, this is to be expected during the beta testing phase and we do not guarantee full functionality at this time.
However, we do guarantee that we're not going to break your requests. Even if the rate limiting functionality is broken, we guarantee that we will "fail open" and your users won't be affected. On the other hand that means in case of problems your origin service may receive more traffic than you have configured. At most that's the amount of traffic you previously received before opting into the rate limiting feature.
Every rule can specify their time frame for which the expenses of the requests are summed up for (
The length of the window has an upper and a lower bound:
- Minimum: 1 second
- Maximum: 1 hour (3,600 seconds)
- Step size: 1 second (no fractions of a second are possible)
Our rate limiting solution runs per region and in the beta version does not enforce a global rate limit yet.
When using a
RequestCount based rule for mutations, the rule will always consume either 0 or 1 points from the budget, depending on whether the rule applies to the received request.
A GraphQL request is technically able to send multiple mutations. The number of mutations within a request does not influence the amount of budget points to be consumed.
If you want to restrict a request from sending multiple limits, you can find an example in our Rate Limiting Rule Examples.
Automatic Persisted Queries (APQ) are not compatible with the Rate Limiting product yet. When rate limiting is configured, any APQ request will be rejected, to disallow circumenventing your rules by using persisted queries.
If you need to have both features work together, please reach out with your use-cases!
Right now only GraphQL requests sent via the
POST verb are rate limited. We will expand to support
GET as well shortly.
OPTIONS requests (e.g. browser preflight requests) are not forwarded to your origin (we handle them in our edge infrastructure) and thus will never consume any rate limit budget.
GraphQL Query Batching is currently not compatible with the Rate Limiting product. When rate limiting is configured, any batched request will be rejected, to disallow circumenventing your rules by using batched requests.
HTTP headers are case-insensitive. We normalize all keys of the
req.headers record to use lowercase string values only.
If you use
Authorization in your HTTP client, it will be available as
If you send somthing like
X-My-Custom-Header it will be available as
The current algorithm to compute the complexity of your request as described in Complexity-based Rate Limiting can't be adjusted. For future customization, the foundational algorithm may be subject to change.
The current algorithm is not aware of the backing GraphQL schema. Only fields that use one of your configured
listSizeArguments are treated as an
Array type field. Relying on the default argument values for page sizes skews the result of the computation, so we recommend to explicitly include any such argument in your GraphQL operations.
Rule limit window resolution
Due to the technical implementation details, rules with a higher limit value are not accurate on the exact second. A window will never be shorter than what the user configured. The maximum difference in seconds from the configured value can be found below.
|From (seconds)||To (seconds)||Maxium deviation (seconds)|