Batching RFC support

[ardatan]

Closes #1661

[changeset-bot]

🦋 Changeset detected

Latest commit: b26382f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
graphql-yoga	Minor
@graphql-yoga/common	Patch
@graphql-yoga/node	Patch
@graphql-yoga/render-graphiql	Major
@graphql-yoga/plugin-apollo-inline-trace	Major
@graphql-yoga/plugin-apq	Major
@graphql-yoga/plugin-persisted-operations	Major
@graphql-yoga/plugin-response-cache	Major
apollo-federation-gateway-with-yoga	Patch
apollo-subgraph-with-yoga	Patch
graphql-lambda	Patch
cloudflare-advanced	Patch
cloudflare	Patch
hackernews	Patch
hello-world-benchmark	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.

[github-actions]

✅ Benchmark Results

     ✓ no_errors
     ✓ expected_result

     checks.........................: 100.00% ✓ 134076      ✗ 0    
     data_received..................: 20 MB   666 kB/s
     data_sent......................: 7.7 MB  257 kB/s
     http_req_blocked...............: avg=1.67µs   min=900ns    med=1.3µs    max=8.64ms   p(90)=1.9µs    p(95)=2.29µs  
     http_req_connecting............: avg=2ns      min=0s       med=0s       max=184.21µs p(90)=0s       p(95)=0s      
   ✓ http_req_duration..............: avg=352.71µs min=221.51µs med=308.71µs max=21.2ms   p(90)=399.42µs p(95)=464.52µs
       { expected_response:true }...: avg=352.71µs min=221.51µs med=308.71µs max=21.2ms   p(90)=399.42µs p(95)=464.52µs
     http_req_failed................: 0.00%   ✓ 0           ✗ 67038
     http_req_receiving.............: avg=24.51µs  min=11.9µs   med=21.3µs   max=8.13ms   p(90)=31µs     p(95)=34.8µs  
     http_req_sending...............: avg=10.81µs  min=4.3µs    med=9.1µs    max=3.21ms   p(90)=13.4µs   p(95)=14.9µs  
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=317.38µs min=197.21µs med=276.31µs max=21.07ms  p(90)=359.81µs p(95)=422.62µs
     http_reqs......................: 67038   2234.484066/s
     iteration_duration.............: avg=441.58µs min=280.61µs med=391.72µs max=21.86ms  p(90)=502.82µs p(95)=571.63µs
     iterations.....................: 67038   2234.484066/s
     vus............................: 0       min=0         max=1  
     vus_max........................: 1       min=1         max=1  

[saihaj]

1. This should have an EXPERIMENTAL_ feature flag to enable this in for createServer
2. As we discussed a little on Slack, we should give some options for user to configure the limit of batched ops that can be sent

[n1ru4l]

Also an interesting but maybe out of scope thing would be to also support streaming the individual results to the client, as they are finished 🤔

[ardatan]

Also an interesting but maybe out of scope thing would be to also support streaming the individual results to the client, as they are finished 🤔

I agree this would be really interesting (defer/stream approach can be used)
Currently this only supports regular results. It might be covered in another PR because we need to think of mapping the responses with the requests in that case.

[ardatan]

I added a new batchingLimit flag to limit the operations, and it is disabled by default. User should enable it by providing an explicit limit.

[n1ru4l]

batching should be opt-in in my opinion, we can take inspiration from the error masking configuration:

batching: boolean | { limit?: number }

[ardatan]

It is already opt-in. See https://github.com/dotansimha/graphql-yoga/pull/1662/files#diff-40184c12fde3ff11137997025804dc55fa5a6455d9feb557320a4ab37c0c1d10R113
I didn't want to allow true because true would mean Infinity but instead here this encourages users to give an exact number for the limit

[n1ru4l]

One argument from my side on why we should use batching: boolean | { limit?: number } instead of just a batchingLimit is that we could potentially group future batching options under the batching key without introducing a breaking change release.

Right now I have no examples for additional options, but past experience showed that this might happen eventually. As for batching: true, the default config could be something like { limit: 10 }`.

[github-actions]

🚀 Snapshot Release (alpha)

The latest changes of this PR are available as alpha on npm (based on the declared changesets):

Package	Version	Info
@graphql-yoga/apollo-link	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/urql-exchange	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/common	3.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/graphiql	2.4.3-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
graphql-yoga	3.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/node	3.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/plugin-apollo-inline-trace	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/plugin-apq	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/plugin-persisted-operations	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/plugin-response-cache	1.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎
@graphql-yoga/render-graphiql	3.0.0-alpha-20220906111732-dd8d69f3	npm ↗︎ unpkg ↗︎

[charlypoly]

/theguild newsletter