Support @defer

[ashah888]

I would like to know when and how the @defer directive can be used using the GraphQL JS library. Is there any plans to include @defer into the graphql library?

[stubailo]

This is the repository for the specification, for the JavaScript implementation you probably want https://github.com/graphql/graphql-js

[leebyron]

Yes there are plans but no concrete date. Stay tuned for the beginning of an RFC, but I plan on running some further experiments before then.

[BruceL33t]

@leebyron Now 2 years later, seeing defer pop up in graphql-java, go and other languages implementations I'd like to hear what's the status of defer for the reference JS implementation? I hope somebody is prioritizing it, since defer is kind of an important feature.

[leebyron]

There hasn’t been any discussion of defer as a spec proposal for years. It was trialed in some other libraries with mixed results.

If, since then, there has been enough success with a trial implementation, then I really hope the people working on that contribute an RFC to discuss standardizing it

[leebyron]

Typically graphql.js only implements specified graphql along with some opt-in use of changes that are being discussed as spec RFC

[BruceL33t]

Thanks for the quick answer.

I just don't get it. In the new "F8 2019: Building the New Facebook.com with React, GraphQL and Relay" video defer is being talked about it as one of the core functionalities, and as if it's already implemented and something facebook is already using https://youtu.be/WxPtYJRjLL0?t=696

Take a facebook graphql-client such as Relay... with the new useQuery hooks in relay-experimental (which apparantly facebook is using acc. to the video) they integrate with React Suspense, and in their recent commits there are references to defer everywhere. Also how else would they make those progressive loaded views they present at that talk. I'm just saying... clearly facebook has it working already, and for some time now, then why not share it with the graphql community, so we don't have to send multiple queries to be able to load slow data without block rendering and without the workaround of doing multiple queries - or look to other languages for server implementations.

Doesn't really make sense for me that this has been postponed so long - it should be one of the most important features. Unfortunately I do not have the technical skills to make this work myself, but for somebody with a good enough brain, I would assume it should be possible to look into graphql-java, go, or even the 1 year old PR in Apollo-server etc. solutions for inspiration, right?

Also maybe facebook could drive this, since they have a solution for themselves.

Love GraphQL but not having defer is a huge limitation when building modern UI's.

[leebyron]

That’s good to hear, actually. I haven’t been involved with the new Facebook project. Last I worked on Relay we attempted to trial implement defer as a build time transform. That sort of worked, but had some serious limitations. There never was server support.

If that’s changed, then I hope someone at Facebook who worked on it can help standardize it.

[josephsavona]

In the new "F8 2019: Building the New Facebook.com with React, GraphQL and Relay" video defer is being talked about it as one of the core functionalities, and as if it's already implemented and something facebook is already using https://youtu.be/WxPtYJRjLL0?t=696

@BruceL33t Thanks for watching!

A bit more context: as implied from the talk, at Facebook we are currently experimenting with support for @defer and @stream directives in our GraphQL server and in Relay. Our plan is to get experience using these directives in our apps in order to validate the concept, iterating as appropriate. We're still early in this process and are not yet ready to begin any effort toward standardization, but we will certainly consider this as we get more experience and feel more confident in the approach.

[michaelstaib]

We are working on this in our .net implementation (Hot Chocolate). The @defer directive can be put on fragments instead of fields which solves a lot if problems.

With the Apollo approach @defercould be annotated to fields and fields had to be nullable which lead to issues where you had to compromise on your data structure in order to be able to defer parts of it.

Although, deferral of content can although be done through batching I find the concept with a @defer directive so much cleaner.

[sorenhoyer]

@michaelstaib

We are working on this in our .net implementation (Hot Chocolate). The @defer directive can be put on fragments instead of fields which solves a lot if problems.

With the Apollo approach @defercould be annotated to fields and fields had to be nullable which lead to issues where you had to compromise on your data structure in order to be able to defer parts of it.

Defer on fragments seems to be in line with what relay/facebook is doing. And makes very good sense.