Data loader batching for subscriptions

[celiocidral]

Data loader batching was disabled for mutations and subscriptions some time ago in #1102 and then reenabled some time later for mutations in #2431. It seems that batching is still not enabled for subscriptions though. Is there a way to enable it, or is that something that is not supported and needs to be implemented?

[bbakerman]

I dont think DataLoader instrumentation makes much sense in a subscritiption world does it?

You have some event that happens, you have a object passed in and you run a subscription selection on it?

I guess if you squint hard enough you might use dataloader instrumentation to collect and then dispatch sub fields.

What's your use case here? Can you explain it more please - perhaps with some type examples.

Thinking aloud without checking deeply, I am not sure instrumentation has the hook points that would work for data loader OR we might need to have a SubscriptionDataLoaderINstrumentation say - a specialised class - because the assumptions on when fields are "ready for dispatch" might be different in a subscription event

[celiocidral]

Maybe our use case is not the most appropriate and we might need to adjust our clients to use subscriptions differently. In order to first render the frontend, our client makes a regular query that makes heavy use of data loaders to avoid n+1 issues. Then once the frontend is rendered, it starts a subscription that asks for the same data that the initial query requested, so it also depends heavily on data loaders. Something along these lines:

query {
  chatMessages {
    message
    author {
      name
    }
  }
}

subscriptions {
  somethingHappened {
    query {
      chatMessages {
        message
        author {
          name
        }
      }
    }
  }
}

We give a great deal of freedom to the client by adding the root query object to the subscription. Our expectation was that anything that happens below the subscription level would behave just like a regular query.

Edit: forgot to mention that the author field is where data loaders are used.

Addendum: we explicitly clear the data loader cache for subscriptions whenever an event is handled, otherwise subsequent events would end up with stale data cache.

[domkm]

@bbakerman What is the rationale for treating sub-fields under mutation fields and subscription fields differently than any query field? I found this behavior to be very unintuitive because, as far as I am aware, the spec only requires special handling of object fields within the root mutation object type and the root subscription object type. At least in my mental model of how GraphQL works, fields inside mutation/subscription return types are exactly the same as query fields.

[bbakerman]

Thinking aloud without checking deeply

As I said I was thinking aloud without checking the code. It MAY work if we allowed DataLoaders to be dispatched.

Subscriptions work like this intternal

The first field MUST return a Publisher of events

For every event on that publisher, we run the execution strategy on that event object as the source. BUT its not as if we start the graphql engine from scratch. It has already run a bunch of Instrumentation methods for this request like graphql.execution.instrumentation.dataloader.DataLoaderDispatcherInstrumentation#beginExecutionStrategy and so on

graphql.execution.instrumentation.dataloader.DataLoaderDispatcherInstrumentation1 s quite stateful by design (it needs to track field levels to know when to dispatch the data loaders)

So I am not sure if this stateful tracking is in the right shape to be simply re-used

See #2922

in my mental model of how GraphQL works, fields inside mutation/subscription return types are exactly the same as query fields.

There are very close to that but they run in a different runtime environment where part of the query has already started some time back.

[bbakerman]

I started a PR to explore the idea of DataLoader support in subscriptions

#2925

What it informed me is that its actually harder than I thought - why?

In a nutshell per per Subscriber + per Publisher emitted event state. See the PR comments for further details