Yaacov Rydzinski

It's here: GraphQL Codegen now supports graphql v17. The CLI, and all official plugins and presets. Just update, re-run Codegen, enjoy. Huge thanks to everyone who tested, filed issues, and helped move PRs forward 🚀 github.com/dotansimha/gra…

we are pleased to announce the release of graphql-js v17 graphql.org/blog/2026-06-1…

v17 release candidate available now => release target of 2026-06-15. Upgrading to GraphQL.js v17 from v16, v15, or even v14? We have you covered at graphql-js.org with detailed upgrade guides! graphql-js.org/upgrade-guides… graphql-js.org/upgrade-guides… graphql-js.org/upgrade-guides…

graphql-js v17 npmjs.com/package/graphql It's happening. Will you be the first to download?

@GraphQL A team effort by many open source contributors but especially of course @E1Goncharov and @JoviDeC . Huge thanks to the amazing community @leeb has built and, of course @Benjie !

Special shoutout to @YRydzinski for all the work all those years. This is the first major release of graphql-js in 4 years!

graphql-js is just around the corner! 🚀 If you haven't already, try the v17.0.0-rc.0 release candidate! npmjs.com/package/graphq…

graphql-js v17 heading our way (on or about) 2026-06-15 Check out the detailed Upgrade Guide @ graphql-js.org/upgrade-guides…

graphql-js v17 target release data === 2026-06-15 github.com/graphql/graphq…

The vibe at #graphqlconf is super great. So nice to meet so many people from the community.

So excited to have presented the newly released alpha of deduplicated #graphql incremental delivery at #graphqlconf 2023... Try it out with the help of the @TheGuildDev's `graphql-yoga`, `graphql@alpha`, and the following shim:

@tannerlinsley @natebirdman Could GraphQL with incremental delivery help even more here, especially with the help of early execution where realizable? Excited to talk about this soon at GraphQL conf, we are getting closer!!! graphql.org/conf/schedule/…

@natebirdman I’d say it sounds like trade offs either way ;)

The most interesting part of async components (RSC, etc) is how they *almost* turn nested routing inside out. All nested layouts including logic *and* data can basically become a components. Which means you're back to composing components together that *feel* like component-driven data fetching... but without the caveats. It's like having an optional route loader in every component. This works today as is because we're okay with waterfalls on the server and have decided that patching "fetch" was a good idea (I don't think it was, but 🤷‍♂️). The part I keep noodling on is how you would be able to get this composition ability back *without* the expense of ditching hoisting/parallelization of data. React's component paradigm is naturally at odds with this pattern, since we have to render to know what to fetch and we can't deep render without resolving any async dependencies. Serial-data dependency isn't *that* common and while it's necessary, it shouldn't be the default/easiest pattern. Most of the time a single up-front serial fetch is all you need to establish any high-level context (a/b testing, auth/session maybe, etc), then you really should be firing off everything else you can derive from the URL together. How can you get this with server components? Do server-components need some kind of compiler? Some kind of data loading convention? How do we get from `/posts/5/comments` to `[fetchPosts, fetchPost(), fetchComments()]` *before* we start rendering and without a router? I have some ideas and I wish so much that I had more time to work on it. Soon, hopefully.

A huge thank you to @UriGoldshtein and @dotansimha of the @TheGuildDev for sponsoring my open-source work! Thanks to the Guild, I am now able to set aside dedicated time for open-source development!

@darrensapalo @Tirumarai Happy to address any questions from the schema stitching side -- have you seen github.com/gmac/schema-st…

@Tirumarai I'm also still studying schema stitching and federation, and weighing the pros and cons of the different things that provide that. So no hard stances here yet- still learning.

Currently studying Apollo Federation, schema stitching, the pains of distributed systems, Apollo Studio, and making Hasura work below Apollo Gateway. Interesting stuff- Trail dies off in 2020 on roadmap/updates Hasura's updates/discussions on Apollo Federation though.

@pkcodes @etiennedi github.com/gmac/schema-st…

@etiennedi Is there a client ☞ Apollo Server w/ schema stitching demo laying around anywhere?

Thanks! Coming very soon this ability will also no longer be limited to text2vec, but allow anything2vec with a module system so everyone can plug in their favorite models and embedders.

@AfricanSinatra @dabit3 What are you missing? Also check out github.com/gmac/schema-st…

@dabit3 I also recently had a look at graphql-tools schema stitching implementation and they have made a tone of major improvements. It's almost on par with apollo federation.

In my opinion GraphQL is the ultimate API gateway – regardless of the underlying databases you are using. If your API is only tied to a single database that’s fine, but where it really shines is when it’s consuming multiple databases, microservices, and Serverless functions.