Why is request batching disabled by default in v4?

[teja42]

I was working on something and found batching to be really useful for my use case but then realised that it is disabled by default. Enabling it very easy but I'm trying to understand the reason for disabling it by default in v4.

I found an issue #5686 that talks about how if batching is allowed then an attacker can send a large number of graphql operations in a single http request to validate OTPs and get around the rate limit. And then there is a pr #5778 that introduced the option to disable it if we don't want this feature. And then it was disabled by default in 25fbc7a (packages/server/src/ApolloServer.ts L262) with no explanation.

Let's talk about this issue #5686. I don't understand how disabling batching would help. Couldn't the attacker send a query like this and bypass the limit anyway?

query validateOTPs(
  $input1: ValidateOTPRequest!,
  $input2: ValidateOTPRequest!,
) {
  firstResult: validateOTP(input: $input1) {
        success
  }
  secondResult: ValidateOTP(input: $input2) {
        success
  }
}

The number of attempts to validate OTP should be properly tracked in a database. That sort of thing should not be handled at the graphql layer.

That being said I'm trying to understand the risks of enabling it and I don't really see any. Can someone please let me know the risks of enabling it?

[glasser]

The migration guide does allude to this:

Not all GraphQL clients support HTTP batching, and batched requests do not support incremental delivery. HTTP batching can help performance by sharing a context object across operations, but it can make it harder to understand the amount of work any given request does.

It's a non-standard transport protocol, and it can actually decrease performance by making every operation in a batch wait until the slowest one is done. At the time of AS4, we felt it was reasonable to only enable the standard GraphQL-over-HTTP protocol by default, leaving future possibilities open for solving the problems solved by batching (eg single context creation) via other mechanisms (eg streaming multiple responses using a protocol similar to incremental delivery).

[teja42]

Thank you @glasser. So it seems like the only downside would be potential increase in response time. If that is the case then assume I'm already doing something like this

query myQuery {
    resourceOne() { ... }
    resourceTwo() { ... }
}

and if I switch to doing this 👇 (with request batching enabled)

query r1 {
    resourceOne() { ... }
}

query r2 {
    resourceTwo() { ... }
}

then there would be little to no difference between both the approaches, correct?

I'm trying to see if request batching can be abused in any way and I can't really find any, like say bypassing rate limits (not a concern because like in my example above the client can send a large query in a single http request anyway).

Is there anything else I should take into consideration before enabling request batching?

[teja42]

To add a bit more, I planned to create two clients, one configured with batching and one without, so I can decide which requests are fine to be sent in batches and vice verse. So I don't think request timing would become a problem.