[gregkerzhner]

I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest.

For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.

In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.

I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.

The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.

In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.

[mikewhy]

> For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it.

Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.

> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.

This is what hooks aim to solve.

[WiseWeasel]

The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls.

The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.