I introduced GraphQL and Relay into our stack so was biased towards Relay "because Facebook". As the app grew, we started having found it more difficult to bend Relay to our needs. For example, its focus on React makes it of little help for client<->server comms in vanilla JS or outside of components (e.g. background tasks, service workers, action functions). It also has limited options for directly accessing/manipulating store data, which further restricts its use-cases within the app.

I initially hesitated to change clients because who could do GraphQL+React better than Facebook? When I first evaluated Apollo a year ago, Relay was still more comprehensive so we stuck with it. But today, everything Relay does Apollo either did first (e.g. subscriptions), does as well (e.g. component wrappers), and often better (e.g. direct cache management). For us, the primary reason to change was that Apollo is "JS-First" rather than "React-First" - this provides more suitable building blocks to design components, interactions, caching layers etc. Our client<->server comms are more flexible, more predictable, and easier to explain/develop.

Apollo 2 introduces apollo engine, network links, and custom client-side memory managers - I was satisfied before, but now I'm excited by the new ways to extend & instrument the data-management layer in our app. I would encourage you to evaluate Apollo as it is a highly competitive alternative from a highly competent team.

1. Relay's documentation is not good enough. There were points where major features were never mentioned anywhere except for a random keyword thrown inside an example. You had no idea what it did and how. Other times you have a basic feature that should be working but isn't, and made very hard to try different things because of the vagueness of the docs. This is getting better, but not quick enough. It's not their focus, I believe.

2. It's clear from their migrations from Classic to Modern and their efforts in evolving the library that their focus is on making Relay what Facebook needs, not what might help a larger community. See 1. This is their right and their choice, but it means it makes it less suitable for my company's usage.

3. Relay imposes certain additional constraints both on the client and the server (and their schema) that might not be needed or desired. Relay uses a super-standard of GraphQL of sorts, with its own flavor of requirements. I'd rather have more freedom/adopt a more global standard with just GraphQL itself, and just have basic guidances.

It can work and it does. But there's too many sore spots that I feel are greater and more numerous than what I've come to expect. Hence why I think Apollo has a better direction going forward.