I'll read this when I get the chance. Perhaps I'll give Relay another chance.
I also found Relay a nightmare to understand. Everything is overcomplicated and messy, which is probably why they're talking about Relay 2.0 already. I was a bit frustrated when I found that this blog post was the most helpful piece of information I could find on Relay, and it tells you to just use FIELDS_CHANGE everywhere and ignore the rest of the mutation config features: http://blog.pathgather.com/blog/a-beginners-guide-to-relay-m... .
Some things that make Relay frustrating:
* Pointless restrictions on what you're allowed to do at the "root" require you to do everything under a "viewer" subnode instead.
* Relay "Routers" are completely pointless and should be removed.
* Mutation configs are totally confusing, and they're tightly coupled to the server-side implementation of the mutation. We have a compile step where the client inspects the schema that was generated by the server. Why can't we generate the mutation configs as well? I know there's probably not enough declarative information readily available, but there should be.
* Relay mutations are only allowed to have one input field and one output field in the GraphQL definition. This is a pointless incompatibility between Relay and non-Relay GraphQL endpoints.
Falcor also exists, and is much simpler, though it has its upsides and downsides:
* You're not allowed to pass any arguments other than the standard from/to pagination arguments. Want to implement faceted search? Too bad. It's "Not a querying language", for some reason.
* It has something called "calls" which are basically the same thing as Relay's mutations but you have a little less control over how cache invalidation is handled than you do with mutation configs. There's no RANGE_ADD, for example. To add/remove items in a list you have to invalidate the entire list. Maybe that's OK though? But it sure is annoying if you're trying to move an item from one list to another on the client side and don't need to wait for the server to catch up.
* No built-in support for optimistic updates yet.
One thing I see in common between React and Falcor is they are both rather complex ways to collaborate with yourself while ignoring events from the outside world. In other words, it's a lot of work to not have pubsub. I guess this is because pubsub doesn't scale? But in the mean time, I'm tempted to play around with Horizon instead.
Really good summary of some of the problems. There is a deeper issue which is that unless your developers understand React best practices really, really well Relay provides opportunities to screw up in a pretty big way. It goes against the 'developer experience' priorities that React was designed around. It's hard to understand and promotes some bad practices for complex applications e.g. binding domain concerns to each component rather than encouraging presentation components. Relay's constraints mean it's hard to control the way the application updates and responds to users. I'm not saying it can't be done but it requires way too much detailed knowledge of the quirks. From an agile perspective it also couples the front end and back end development too tightly.
We have since moved to Redux and are going to back out Relay from the application we used it in. With all of Redux's issues (ceremony, boilerplate, etc) it provides a standard model for us to reason about, and a decoupling of data retrieval from presentation.
Quite the opposite. Relay allows you to write proper presentation components and then wrap them in data-provider components. This is a step toward isolation of presentation and data management. If you could move all methods that actually manipulate the data up out of the presentation components and into their wrappers, that's even better.
Unfortunately, the parent component has to reference the wrapper instead of the wrapped component, so you get this alternation between presentation and data management. But at least the leaf nodes can be considered reusable presentation components with no coupling to the data layer.
Anyway, everyone is doing this these days. Check out: