Apollo Client 3.0 Roadmap

[hwillson]

Hi all! Once summer vacations are out of the way, we'll be hashing out the Apollo Client 3 roadmap. We have an approximate idea of the new features / functionality we want to get in place for AC 3 (based on open feature requests from the community, breaking changes required to work with new versions of 3rd party libraries, and a few additional ideas of our own). Once we have a draft of the v3 roadmap ready, we'll share it here for feedback. It's going to be an exciting release! 🚀

UPDATE (2020-04-27): The most up to date roadmap can be found here. We're aiming for an AC 3 RC in May 2020.

[joshribakoff]

I am in suspense 😉

[danilobuerger]

@hwillson If v3 is breaking anyway (looking at semver), it would be really nice to consider moving query and mutate to return Observable instead of Promise. This would then allow easy cancellation for example in react components.

See https://reactjs.org/blog/2015/12/16/ismounted-antipattern.html https://medium.com/@benlesh/promise-cancellation-is-dead-long-live-promise-cancellation-c6601f1f5082

[mbrowne]

Is the in-development v3 code being committed publicly on github somewhere? Or all still behind the scenes at this point?

[hwillson]

Hi all - sorry for the delay on this. We've been bouncing around a lot of different ideas, and have been considering several different approaches to Apollo Client 3 (and how it will fit within other changes/updates coming in the Apollo ecosystem). Long story short, we have an initial plan of attack ready for Apollo Client 3.

Note: We're actually hoping to split things up a bit, so we can get some of the non-breaking features out sooner than later (in a 2.x release). All of the functionality listed below will be in Apollo Client 3, but🤞some of it will be available sooner.

Features

At a high-level, the big ticket Apollo Client 3 items that we're planning on addressing are:

1. Building cache invalidation / deletion / garbage collection capabilities into core.

• This is hands down the most requested outstanding feature.
• Main related issues: Umbrella issue: Cache invalidation & deletion apollo-client#621 and Umbrella issue: Cache invalidation & deletion #4

2. Bringing apollo-link-state capabilities into core.

• apollo-link-state will no longer be a separate package. It will be adjusted/refactored/merged into Apollo Client, and it will become part of the Apollo Client public API.
• Many of the existing issues outlined here will be addressed at the same time.
• We're hoping to have some of this work completed and released a bit earlier, in Apollo Client 2.x.

3. Merging apollo-boost into core.

• Apollo Boost does a great job at getting people up and running with Apollo Client quickly, using sensible defaults.
• Unfortunately, presenting 2 ways of using Apollo Client, via apollo-client or apollo-boost, has led to a fair amount of confusion among users.
• The Apollo Boost project will be retired, and all existing functionality will be made available via Apollo Client itself. This means apollo-client will provide a quick getting started (minimum config) approach, that can be overridden with additional config elements as needed.
• We're hoping to have some of this work completed and released a bit earlier, in Apollo Client 2.x.

4. Address many (hopefully all) of the outstanding refetch related issues.

• Refetching and having data disappear because of differences between incoming data and data in the cache, is a long standing issue.
• There are technical reasons why this is happening, and available workarounds that help mitigate this problem (like using Apollo Client's mutate update function to merge results and cache entries manually, or using React Apollo's partialRefetch option to refetch when a discrepancy is found).
• That being said, this has been a large area of frustration for many users. We will be looking into a new approach for handling refetching that helps avoid these discrepancies.
• Related issues (just a sampling - there are many more):
  • Under-fetching fields of new objects in mutations silently breaks mounted Queries apollo-client#3267
  • Mutations Nullify Intersecting Cache Objects apollo-client#3468
  • Updating with missing data makes query fail silently apollo-client#2920
  • Mutations which don't satisfy watched queries cause queries to return no data and no error apollo-client#2847

5. Focus on getting bundle sizes down.

• The apollo-client bundle size will be reduced - full stop.

6. Address issues / PR's / outstanding code changes that we've flagged as breaking.

• This list it still being worked on. TBD.

Design

Design work is underway, and detailed designs will be shared in separate issues, for feedback.

Timeline

We're aiming to have this work done as soon as possible! 🙂

Related Work

Since Apollo Client and React Apollo are closely related, React Apollo will be bumped to 3.0 when Apollo Client 3.0 is released. Any outstanding React Apollo breaking changes will be included in this release, as will updates required to align React Apollo more closely with upcoming React changes (like React Suspense).

Thanks all - let me know if you have any questions/comments. 🚀

[JoviDeCroock]

I think that 2 and 5 are a bit contradictive since offering a zero-config solution would imply having some pre-set dependencies (which could or could not be overridden). Unless you would just make them peer dependencies (blows up console though) these would increase downloaded bundle-size.

I may be thinking about this in the wrong way though so please correct me if i'm wrong.

[green-pickle]

@JoviDeCroock you're not wrong, from the above roadmap core will have more things you never need (like apollo state or apollo boost, which will also bring their dependencies), hope tree-shaking will remove them (it won't).

We can thank devs who can't read the docs. Same thing happened with apollo-server 2 where separate middlewares were removed and combined into an unusable monster just because newbies couldn't combine two functions.

Let's also hope HOCs won't be removed from react-apollo.

Enjoy 😉

[joshribakoff]

@jovidecrook the point is they are consolidating packages. Peer dependencies are when you have separate packages, e.g. React is a peer dependency of react-Apollo.

@green-pickle what build tool are you using that has tree shaking but still bundles modules you don't import? If you don't import it, it won't be bundled. That's not even tree shaking that's just basic bundling. Tree shaking will remove code you did import but didn't use. I am a dev who reads the docs and this is my understanding of tree shaking. Your comment comes off a bit negative and based on my knowledge of tree shaking it seems inaccurate

[JoviDeCroock]

@joshribakoff Yes but an internal zero-config can't really be seen as a peer dependency in my opinion. These will be imported in the internal code so will always be included in the bundle and will be used in the internal code making tree shaking irrelevant.

In my opinion if you want to go bundleSize first, the focus should be placed on a really clear distinction between zero-config client (boost) and freedom DIY

[jbaxleyiii]

@green-pickle @JoviDeCroock There is definitely a balancing act between bundle size and features here that we need to manage, but after some investigation, we think there is a lot of straight up code removal that we can do which will make a big difference. In making a lot of composable parts, one of the trade offs is the desire for abstract components that carry extra weight of open interop we can remove.

With @benjamn and @hwillson on the case, I'm super optimistic about having both a great getting started experience and a production sized client :)

Also @green-pickle I think you'll be happy with some upcoming changes on the server. We hear you loud and clear about some missteps there and will have changes soon that I hope you will love

[danilobuerger]

@jbaxleyiii is there a roadmap for apollo-server ?

[jbaxleyiii]

@danilobuerger 🔜 🔜 🔜

[danilobuerger]

@jbaxleyiii maybe you could already create a skeleton issue for that, like @hwillson did here, so we can subscribe and get notified once the roadmap stands? that would be awesome!

[JoviDeCroock]

@jbaxleyiii Thanks for the information. I'm looking forward to it!

[joshribakoff]

@JoviDeCroock consolidating packages does not necessarily mean they're going to couple them like that

[green-pickle]

@joshribakoff from my experience, tree shaking doesn't always work as you expect, check this one: webpack/webpack#2867. It existed for a very long time while this feature was praised in the docs and articles with simple two function examples while not showing it didn't work in a lot of simple cases. Since the issue is closed maybe it's better in v4. A flag was also added to make it work, but I believe very few packages use it. This is why I'm so skeptical when I read tree shaking tales :)

@jbaxleyiii oh, great news about upcoming changes in server part, would love to see them ❤️

[ghost]

🙂 really interested to see how 1 shakes out

[Elfayer]

Will there be a migration script/documentation for people starting a project today with the current AC version?

[koresar]

Would be also very good to see similar roadmap for the Apollo server. It much needed there.

[archseer]

I would love to see #2 on the v3 roadmap as well -- it's kind of tedious to have to manually parse dates/datetimes in every component

[gregwym]

Agree with @archseer. GraphQL server have mature support for custom scalar type for long.

[edslocomb]

Anyone else interested in improved test tooling/docs?

I dunno about other projects out there, but for ones I work on it sure would be nice if we could easily stub queries/responses and use them to test subsystems of components linked via Apollo...

[spyshower]

Anyone else interested in improved test tooling/docs?

Hell yes!

[hwillson]

Hi all - we've just published a new iteration of the Apollo Client 3 roadmap here:

https://github.com/apollographql/apollo-client/blob/master/ROADMAP.md

Work is well underway, and we should have an RC ready towards the end of October. Thanks!

[UpsidePotential]

I hope I am not reading too much into the roadmap. Seems like React is going to be first class. Are you going to continue to support other frameworks such as Angular?

[hwillson]

@UpsidePotential The React Apollo project is being merged into Apollo Client to help reduce the maintenance overhead that comes from managing these projects separately, and to give us a way to provide a better out of the box getting started experience. We're definitely still going to support other view integrations, and will outline ways to use Apollo Client 3 without bringing in any of the extra React weight, if it's not needed.

[jbaxleyiii]

@UpsidePotential to further what @hwillson has said, the React integration has always been at a higher level of support after I joined the company since it was no long "community maintained". We are moving it in like @hwillson said to ease our maintenance burden but Apollo Client is, will, and will always be usable by any view layer or none at all ❤️

[geekox86]

Greetings gentlemen,

Thank you for all the good work.

I suggest to keep the react integration as optional one like @apollo-client/apollo-react

Also the docs for the core vanilla apollo-client needs to be enhanced with examples that are just vanilla JS (no react or view integration layer).

[seanharr11]

Thanks for all the great work fellahs! This is such a great tool.

I think if Apollo is going to address #1 then it'd make sense to do so now, or close the issue (and crush my hopes and dreams).

We would break interface of those relying on an exception getting thrown if a query DNE in the cache when it is read (which we can justify in a major release).

IMO we would address a class of runtime bugs produced when a query's cache is read from before the query has ever been run. In practice this occurs quite often, especially surrounding newly released features that require user input before viewing.

[adamtysonsmith]

Is the 3.0 documentation available anywhere yet? Really looking forward to it and thank you all 😄

[levrik]

@adamtysonsmith Looks like it's available here: https://www.apollographql.com/docs/react/v3.0-beta

[morrys]

Hi guys,
I would like to propose you to export the function markMutationResult and to be able to use the function generateUpdateQueriesInfo through the QueryManager.

These changes allow easier integration into the library that I created for Apollo offline capabilities.

In apollo-client 2.x.x they were accessible through the client store.

if you are interested, let me know so I will be able to offer you a PR, as soon as I can.

Thanks,
Lorenzo

[thojanssens]

Hello 👋 can the roadmap be updated?
It says Completion date: Full RC available end of October 2019
But it's still in beta if I'm not wrong.

[SimenB]

apollographql/apollo-client#5116 (comment)

[Deelux]

Any news on when Apollo 3.0 will be released?

[hwillson]

@Deelux we've very close to moving to an RC. There are a few remaining pieces of functionality we want to get into place before doing that, and we still have a good chunk of docs work to finish up. We can't share a definitive launch date yet (as every time I do I'm wrong 🙂), but you can try things out today using @apollo/client@beta. We're using the beta in production ourselves and it's working well for us.

[Deelux]

@hwillson Anything I can do to help?

[hwillson]

@Deelux at this point testing out the beta and reporting any issues you find would be a big help. Thanks!

[klaussner]

Given that caching improvements are an important part of the next release, would you be open to considering apollographql/apollo-client#4141 for 3.0 as well (see my comment in the issue thread for details)?

[oshalygin]

One of the biggest pain points right with the beta is that you can't disable the cache like you could with the previous release @hwillson

#91

Curious on your thoughts if this can be introduced in a future release or if its going to be part of RC?

[0xMarkian]

@Deelux at this point testing out the beta and reporting any issues you find would be a big help. Thanks!

@hwillson seems like beta40 is breaking devtools (works fine on beta39)
apollographql/apollo-client-devtools#250

[kritijain2269]

Any news on when Apollo 3.0 will be released?

[SimenB]

apollographql/apollo-client@0f21039

[sahand-javid-csod]

How far are we from Stable version for v3? Should we start using rc0 for production?

[jainnirmal1992]

Any news on when Apollo 3.0 will be released?

[hwillson]

This was done!

[mnpenner]

Oh yeah.. looks like it was released about 8 months ago. Changelog