Same, we really need this patch in production for async iterables. We have our event loop blocked by the execute method when a resolver returns a large array of results and that method needs to generate promises of all field resolvers.

As Jovi says, @stream and @defer are still being developed; if you wish to join these efforts you may join the WG: https://github.com/graphql/defer-stream-wg/ . The latest spanner in the works is described here for example: graphql/defer-stream-wg#100 (though you may want to familiarize yourself with the previous work in order to understand the complexity of this specific issue).

We are also in the process of getting the agreed parts of stream and defer through the spec review process, including bringing small parts for review to each main GraphQL WG and splitting the work into smaller more manageable chunks. Incremental delivery is a very large feature, with a lot of potential pitfalls if implemented naively (see the response explosion attacks easily possible in the pre-June 2023 response format, for example); coming up with a solution that works for all clients, isn't too complex, but doesn't suffer from these issues (or at least not as much) is a significant undertaking - and the people working on it are all volunteers.

I would add to that that one of the best things you can do to support the work is to start using it already (with extreme caution) and provide feedback from your real use case in production to the WG
If you need help using these today feel free to reach out

@Urigo @benjie @JoviDeCroock thank you kindly for your efforts and replies here. It is heartening to hear that the work on these topics is ongoing.

I don't think I'm the right person to join the WG: I'm too much of a pragmatist and uninvested in the deepest edge cases to be much help hammering out the final details. For example, my suggestion for the case that you shared @benjie would be to simply disallow that combination of effects (i.e. simply deem the query invalid). Since @stream and @defer don't yet exist anywhere officially I imagine that to be feasible. I believe the community would benefit a lot more from having a working (if ever so slightly limited) implementation today, rather than waiting to solve cases like that to perfection. Again, just my 2c – and my currency probably isn't worth much in the world of standards and specifications.

It is very helpful to hear that v17 alpha is not considered unstable, but rather that certain edge cases need to be ironed out, and adoption paths need to be clarified. FYI for us the only challenge updating from 15.x to 16.x was the amount of TypeScript errors the change caused – presumably Apollo Server also smoothened out some of the differences under the hood as well though.

If there is no specific reason not to use v17 in production, I would be happy to give it a shot and report back with any issues we may run into. FWIW we're using Apollo Server 4. We just started the new year and have bitten off probably more than we can chew already, but I'd be happy to introduce this change soon to give it a shot.

For example, my suggestion for the case that you shared @benjie would be to simply disallow that combination of effects (i.e. simply deem the query invalid).

That’s currently the leading proposal so it sounds like you’d fit right in!

For what it's worth, we have been running v17-alpha in production for the past 6 months without a single problem on a service :)