Well. That's highly dependent on your needs. And not directly a concern of pathom. You could count request, calls of mutations, access to attributes... Whatever. Maybe you could look into how existing, big GraphQL APIs handle rate limiting? Like from GitHub? https://docs.github.com/en/graphql/overview/resource-limitations#rate-limit

I'm guessing that it would need some kind of context in Pathom, where different resolvers can accumulate the cost, and abort or truncate the request if it gets too costly. Of course if the cost could be calculated based on the query without knowing the data (so depth, without knowing the width of the data), a proxy could already handle it in front of actual pathom

I think making it by resolver is a reasonable path, since you can kind estimate the cost of each

In the github example, they know the cost of query since all the levels are limited in width. But I was wondering if it's possible to keep track of the result width while resolving, and somehow abort. Recording the cost from realized result and stopping future queries if the quota ran out would be easy enough, I guess

You can write a plugin for this. Not the same, but maybe an example you could work of: I wrote an access plugin that keeps a set of "allowed" inputs for a request. For each resolver call, I check if the input of the resolver is in my allowed set. If it isn't, I check if it should be allowed and if so, add it to the set. If not, I don't run the resolver. https://github.com/hhucn/decide3/blob/master/src/main/decide/server_components/access_plugin.cljc Why could this be relevant for your situation? 1. It has a per-request store. (In your case, you could record cost.) 2. It uses the store to decide whether to run a resolver or not. (You could check: Am I over the quota?)

if you are using Pathom 2, things are very similar, just a different plugin entry point

That's great! I'll read more about plugins when I'm a bit more rested, Monday latest