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?