Author here :) I used Apollo for the first time in this application, it was great throughout the implementation, but this was truly the worst part to implement. It came with multiple flaws in my eyes which are perhaps due to Apollo being in early stages or me just being inexperienced with it.

- updateQuery was a deprecated property when I implemented it and one should use update instead. But it wasn't and maybe still isn't possible to use update for the fetchMore scenario.

- I couldn't find any real consensus on keeping immutable data structures in Apollo. Since I favor to work with it, I kept it this way. However, in the case of pagination and deep nested data structures, you would have to fallback to a library to deal with it. Apollo adds their own immutable helper to the whole tech stack which means to adapt yet another API... I wouldn't want to do it and I think it's a bad decision to introduce yet another immutable helper. That's why I picked the object spread operator.

- I would hope that updateQuery goes away and one would be able to use writeFragement in the update property to update the paginated data. If it's possible, I would love to speak more about this topic with people more knowledgable than me in Apollo :)

Having just written something similar to that, I agree, the pattern for server-side pagination is pretty clunky. However that is a client-specific implementation detail - GraphQL is an implementation-agnostic spec.

That pagination is using a spec relay and apollo advocate for:

https://facebook.github.io/relay/graphql/connections.htm

It's not really a GraphQL specific method though. I've seen the same sort of pagination used on REST APIs.

I think the complexity of it on the client could easily be abstracted away as part of apollo or as a separate package.

Honestly, `doFetchMore()` represents all of the worst aspects of "modern" javascript -- incredibly terse syntax that does little to help the developer understand what is actually happening.