Search posts, tags, users, and pages
How will Apollo be a long term, sustainable solution superior to Relay?
Thanks for the question, Sergio!
First, I think there is room for many great GraphQL clients in the ecosystem. Here on the Apollo team, we think GraphQL will be the next big way to load data after REST, so we think the ecosystem is just getting started and eventually there will be tons of options for servers, clients, tools, and more. So it's not about superior - it's about looking at the different options out there and seeing which one meets your needs the best. But we're committed to making it a long-term project -- we're already using it in production in two of our apps, and will be continuously developing it over the coming years.
Our goal is to build a sophisticated GraphQL client that can be a more flexible and hackable alternative to Relay. Relay is, at the time of writing, quite opinionated about a variety of development decisions, in large part because it is focused primarily on Facebook's application development needs. It only works with React, it requires specific schema features on the server around pagination, mutations, and refetching individual nodes, it is coupled to specific concepts about routes, fragments, and containers, and only supports several specific ways of using mutation results that don't always match the situation. If you like this approach, then Relay is awesome - it does a lot of work for you. I'd encourage you to keep using Relay if you love it.
We found that not all of these opinions worked for us, and we needed something that we could hack on to build new features, and easily debug by inspecting store state. So while in the overall architecture Apollo Client is extremely similar to Relay, with a normalized cache of GraphQL data, we decided to go with a few different decisions:
I could keep going on about the differences, but you can see the trend - we're going for a more configuration over convention approach, so that you can take advantage of Apollo Client regardless of your client architecture, schema, etc.
Lastly, once Apollo Client becomes production-ready (we have an issue open now to track necessary changes before a 1.0 version), we can use it as a platform for us and the GraphQL community to experiment with new GraphQL features and approaches, including subscriptions, live queries, offline support, and more. Because it's build from the ground up to be flexible, we envision these features will be relatively simple to add once there is a need for them.
If this kind of transparent, hackable, and flexible GraphQL client sounds like a good idea to you, I'd invite you to contribute to the repository! There are already 29 contributors, and we are looking for more great ideas, discussions, and improvements.
Thanks a lot Sashko, will take a look at the repo for contributions!