Hi there,
I know rate-limiting has been a topic of discussion in multiple conversations here but I’ve not really seen any related information about how rate-limiting would work with GraphQL. I’ve seen possible solutions like the ones suggested here, but I don’t think these really apply when using Fauna’s GraphQL API.
Are there any inbuilt rate-limits using the GraphQL API or is there any way/any plans in the future that would let us customize them?
Thanks,
Ramon
Hi Ramon,
Giving our users the ability to set rate limits is a feature we have been discussing internally, although it is not planned for immediate work in our road map. Our plan is enable users to define multiple rate limits, defined in terms of number of read, writes, and compute ops consumed in a given interval of time. Defining rate limits in these terms makes sense, as these are the the units we aggregate on for billing and usage. Additionally, a given GraphQL query essentially translates into a set FQL queries at execution, each of which consumes a set of read, write, and compute ops in the backend. Our GraphQL API would then be rate limited based on the consumption of those operations, just as the FQL interface is.
Rather than setting a rate on per query basis, we are instead thinking of assigning rate limits on per authentication key basis. Our thinking here is that you may wish to set different rate limits for different use cases and applications served by Fauna, and need to set distinct rate limits appropriate to each application’s load. You would create a rate limit at the right level for a given application, and then assign that rate limit to the authentication key the application uses to connect to Fauna. All queries authenticated by that key would then be governed by the rate limit assigned to it.
Would this feature work for you as I have described it?
That would work for some use cases like an authentication service that logs users in for example, but it might also be good to document or role based rate limiting for different UDFs. This will work well for the previous example because now the users that are authenticated by the service are also rate limited.