Is there an expected timeline for the stable release of 17.0?

[bsmith-self]

We're waiting to upgrade from Node 14 because we don't want to go to an alpha version of graphql for Node 18 support, but trying to decide whether we need to go ahead and upgrade to 16 and then go to 18 a few months from now when 16 is EOL, or just wait and go straight to 18 (if the stable graphql release is right around the corner)

I realize these things can be uncertain, but any information about the time-scale (days? weeks? months?) would be appreciated

[torbjornvatn]

@IvanGoncharov any updates on this!

We really need #2757 Support returning async iterables from resolver functions in some of our production environments, but we have to keep building a separate version with the alpha version because we don't want to use it in all our environments

[philippemiguet]

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.

[leszekhanusz]

See also graphql-python/gql#427.

Is there anything blocking a stable release of 17.0?

[jarlefosen]

Hi, is there a roadmap for what's needed in order to release v17? cc @IvanGoncharov

[ephemer]

I'm curious why 17.x has been "stuck" at alpha for two years. Is it an indication that the stability is not where it should be on certain features? Is there something the community can support with?

We would love to use @stream and/or @defer (we can model our data either way – we just need delayed responses of some kind) but it's unclear to us what is blocking these features from reaching the mainstream, or even a beta channel. alpha sounds very unstable but I'm not sure it truly is.

@JoviDeCroock would you be able to say a few words about the decision-making here? Is some part of this feature set very unstable and others relatively stable? Is there some asynchronous response feature that could be backported to 16.x instead? Or how can we best interpret the current situation? Thank you!

[benjie]

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.

[Urigo]

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

[ephemer]

@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.

[benjie]

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!

[philippemiguet]

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 :)