After working with Apollo for a couple weeks on a non-trivial side project, I'm particularly happy with how unopinionated the library is. While it's super hip to complain about JS fatigue these days, Relay just wanted to make too many decisions. In that sense, it's a pro and a con: Relay will make more decisions for you, but will present difficulty if you've already made some of those decisions yourself.
Apollo's using Redux is great. The model and API are well understood so it's easy to bring developers on board. Relay seems to follow the same principles, but does them in its own way.
Relay is also opinionated about your server's responses. I know that the cursor pattern with edges and nodes is great for performant pagination, but then our schema has to conform to that spec and I really don't enjoy spending time explaining why we can't just get that user's photos, we have to get that user's photos' edges' nodes. Graph theory has a place, but it's not that close to the frontend, IMO.
More than anything, it seemed very easy to get up and running with Apollo. After reading lots of Relay docs, it still took a lot of experimentation and effort to get this running to begin with. I am very happy with Apollo's docs.
Before we started building Apollo Client, we actually tried Relay, but found it difficult to adopt, so we started a community effort to build a more flexible GraphQL client. Our main goals were to make incrementally adoptable, compatible with all view layers and easy to understand/debug.
While Apollo is easier to adopt and use, it's still under active development, so it's not as stable as Relay, and hasn't been optimized for performance the way that Relay has.
/disclaimer/disclosure/ - when you disclose something, it's a disclosure. (Sorry, personal bugbear, along with e.g. / i.e. confusion. Both are rampant on HN! :) )
