Apollo-client: Pagination / updateQuery / fetchMore deprecation status

[jacdx]

We lost an over a day trying to figure out how to get Apollo Client 3 type/read policies working to replace the pagination that we are doing with fetchMore / updateQuery. We can't afford to lose any more cycles on it, and realized at the end of the day, it just shouldn't be this hard.

The whole reason we went down the path was due to the deprecation warning message that is now constantly popping up in our builds. But IMO that message should not have been shipped in the client, until there was a clear, validated path forward, and there is not currently. The documentation is not clear or complete enough to cover beyond the most basic use cases. Even to get those working, required scouring of github, stackoverflow, spectrum, the docs, videos, and looking through AC source, which was anti-productive. But most people don't just paginate simple queries, there are filters, ordering, etc. and a lot of people are stuck or confused about how to move forward. These are not advanced use cases, it's just pagination and filtering.

Apollo client has found way it's way into an important part of our (production) stack (and many other teams) and that means changes should be made carefully and strategically. We're now 2.5 months after 3.0's release, and there is still outdated, and incomplete, and conflicting documentation on the website? You guys have 50M in funding, why isn't more it getting allocated to making sure the core of your ecosystem, Apollo Client, is solid?

Between this and the ever accumulating list of unresolved issues in Github, we are carefully considering the cost/benefit of staying on Apollo client.

[hwillson]

Thanks for taking the time to comment with your concerns @jacdx. We're working on changes to the pagination (and other) docs, all of which is being tracked here. We're also working on improvements to Apollo Client almost every single day, to help make it an even better choice for managing client side data graphs, and working with remote GraphQL endpoints. The Apollo Client team is currently relatively small, made up of 5 engineers covering 4 projects: Apollo Client web, Apollo Client iOS, Apollo Client Android, and Apollo Client devtools. Because of this we have to choose and prioritize our focus carefully, which unfortunately means some issues take more time to address (like the issues you've raised). The good news is, we're going to be hiring new team members shortly, but I know that doesn't help you today.

In the meantime, please remember Apollo Client is an open source project. We're always up for community help, so if there are specific parts of the docs that you want changed, if you can itemize the main pain points, or even better yet put together a PR, we'll definitely take a look.

As for redirecting more funding $'s into Apollo Client, it's important to note that Apollo is a for profit company. Being profitable is how we plan to keep building awesome open source MIT licensed developer tools, and enabling community members and companies to use them for free. OSS has changed the lives of every person on the AC core team in so many ways, and we're extremely thankful that we're in a position to give back. Doing this though means we have to keep the "Apollo Graph Inc." lights on, which means we have to make sure funds go into developing our commercial offerings as well. It's definitely a balancing act, but we're constantly re-assessing where things are going well, and where they aren't. Feedback like yours helps us improve, so thanks again!

[jacdx]

Thanks Hugh quick response. I understand your guys' position, and certainly am both empathic to the team (I see @benjamn is up to his eyeballs in this stuff, as I'm sure you all are), and appreciative of the work that it takes to do what you guys have done and are doing in general and for OSS. I can also understand the need for more time to sort this out. The urgency was really created by the deprecation notice being pushed out (in our opinions prematurely), which teams are now seeing (every day, all day in our case), and wanting to get rid of.

The specifics of our use cases aren't really different from the ones that are already ticketed here and in spectrum. For now, we are backing off from refactoring any updateQuery stuff and client upgrades relating to it until things are more solid.