Apollo-server: Defer usage

[janhartmann]

On my Apollo Server I am running:

"apollo-server": "^2.2.5",
"express": "^4.16.4",
"graphql": "^14.0.2",
"graphql-tools": "^4.0.3",

But I am unable to try out the defer directive, as my server is returning: Unknown directive "defer".

I am unsure how to enable this feature. I have read all information I could find on defer, but no matter what I do I can not enable it. On my client I am also running latest version of React Apollo.

How do I enable defer? :-)

[jaschaio]

I got the same issue using apollo-server and apollo-server-express.

package.json:

"apollo-server": "^2.4.0-alpha.0",
"apollo-server-express": "^2.4.0-alpha.0"

Within the defer support doc it says that I have to explicit enable the support when using apollo-server-express but without actually explaining how to add my custom handler.

[janhartmann]

I managed to find some updates on defer from the #defer channel on Apollo Slack Community:

@hwillson wrote on October 18th 2018

Regarding the status of the @defer PR’s; we’re in the middle of some pretty extensive Apollo Server changes / refactoring behind the scenes, all of which will impact how @defer support is handled on the server. Once those changes are done, we’re going to circle back and get all of the @defer PR’s updated, and pushed out. This likely won’t happen until after Graphql Summit though, so possibly mid to late November.

And on December 18th 2018:

@defer support touches on 4 different projects (Apollo Client, React Apollo, Apollo Link, and Apollo Server). Things are pretty much ready to go with the first 3 (other than the @defer PR’s being out of synch, but those are easy to fix). The issue is the pending changes required for Apollo Server, to make everything work. The POC changes for Apollo Server work, but we’re concerned about their performance (not a fault of the current Apollo Server @defer PR; it’s a fault of the current Apollo Server architecture). We’re planning on making several changes to Apollo Server to not only accommodate @defer support in a safer and more performant way, but these changes will also open the door to other similar changes, like @stream support (which is also on our list). We’re not quite ready to start working on these changes in Apollo Server, but this task is being tracked and is in our backlog (and I’ve flagged it as being high priority).

I can really only speak for @defer support in Apollo Client, React Apollo and Apollo Link (since I’ll be helping get that work in place). The @defer functionality in the outstanding Apollo client side PR’s is highly dependent on the Apollo Server @defer support approach. So for now those PR’s are at a bit of a stand still, until the server side approach is nailed down. @martijnwalraven and @abernix can help answer questions about the plans for Apollo Server @defer support.

@martijnwalraven chipped in with

Unfortunately, we haven’t been able to get back to this yet, so we don’t have anything to share. what needs to happen is basically an overhaul of the apollo server architecture to support pluggable transports. right now, only the http transport runs through the request pipeline, meaning using websockets doesn’t support most of the apollo server features. we need to change this, and also define a more flexible response api in the request pipeline to support subscriptions, defer and stream. (we’ll likely want these to be runnable on top of http as well, possibly using sse or plain multipart responses.)

[dude-awesome]

can you please give a hint on the docs that @defer is currently not working and a upcoming feature?

[michaelshiel]

I'm curious if there is a reason to not release the client-side support on it's own, especially given that graphql-java just merged defer support.