Apollo manages your data store automatically. It uses Redux internally. Because Apollo wraps the queries and mutations, it smartly caches data and only fetches the minimal amount necessary to build the page. Apollo reduces the amount of Redux CRUD boiler plate dramatically (by as much as 2/3 or more).

There are no traps there, everything is configurable. The documentation is really clean. Highly recommend Apollo.

Once you have this stack wired up, it empowers you to be quite nimble with your development.

> everything is configurable

Arguably that's it's own trap. Convention over configuration has saved millions of man hours in e.g. Rails projects, but a lot of JS land involves sinking a lot of time into the opposite.

You can just stick with the defaults until you run into issues or need advanced features like optimistic updates or real-time communication via websockets. Apollo also makes it easy to long poll if you're having consistency issues for some odd reason.

Declaring what data your UI binds to is not a side effect, so co-locating GraphQL queries with your component doesn't necessarily introduce side effects. You don't have to co-locate GraphQL mutation queries to your component, you can just have your event handlers (or other mutation-creating events) handled elsewhere in your app.

> What happens when two components used in two totally different areas of a single page need common data? Relying on a cache feels like a hack.

When declaring what data you rely on is as simple as a GraphQL query, it's basically like declaring what data goes in your component. It's NOT like building ORM layers directly into your UI components.

It certainly does introduce side effects (by default, for Apollo or Relay):

* A network request is kicked off if the cache doesn't contain the data the component declares a dependency on.

* other components that depend on any part of the requested subgraph will update when the response comes in

* query observers (which HoC'd components really are) will similarly fire, potentially triggering other side effects in your application

If you include enough in your definition of side effect, everything must have a side effect. Otherwise you wouldn’t be doing it. A pure function that adds two numbers and returns the result has left your system in a different state than it was in before it ran.

Data binding has side effects and the implementation of the thing doing the binding may cause things to happen, may cause some state to change. But I still wouldn’t consider the declarative data binding itself to have side effects.

The components are coupled to the structure of the data, not the graphql query. Where would you rather make the http requests? Somewhere in the redux layer? That's basically what Apollo client does anyways, it just reduces boilerplate.

Although I think coupling components with data structures is the smaller benefit. The real benefit of graphQL is not the client architecture, the real benefit is decoupling frontends from backends, unifying disjointed backends, and efficiency.

In the name of efficiency though, graph QL is projecting a graph into a tree which involves denormalizing & duplicating data in the response. This is where netflix's falcor is cleaner. Check out my little graphQL demo repo / read me https://github.com/joshribakoff/graphql-demo I write more about the benefits of using graphQL, and also the down sides.

So basically you prefer something more along the lines of Model View Controller. Me too. When React was first released it was advertised as “the ‘V’ in MVC”. Unfortunately the developer community took it in a different direction.

How so? It still is exactly that.

You can add additional layers/groupings/couplings but that isn't React doing that...

> Is this idiomatic?

Not for React but it's basically the exact idiomatic use case of Relay. GraphQL or React don't require it at all however.

It's not really coupling queries with components, only fragments. You can build a query with fragments so the query is definitely decoupled.

If two components used in different areas needed common data that would get pieced together through the fragments. Just depends how you architect your app.