Comment by Sergio del Rio on "Ask anything to Apollo Team"

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:

Apollo Client is split from the start into a core implementation that is completely independent, and view layer integrations for React and Angular 2. This means it's easy for other people to build integrations for whatever view layer they need, like Ember, Vue, or more, without needing to reimplement any core logic.
Apollo Client doesn't rely on a specific schema from the server. The current features about mutations work with any GraphQL mutation you can think of on the server, and the design for pagination we are currently working on will work with all kinds of pagination formats - page numbers, pages with cursors, and relay connections as well.
Apollo Client doesn't require any specific build plugins. As long as you can install the NPM package, you can start using it without needing to add anything to your build setup. This is because none of the functionality depends on having schema information at runtime. You can still use static analysis tools like eslint-plugin-graphql to validate your queries at build time, but it's not required.
Apollo Client is based on Redux, which gives us great insight into how the store is changing over time and makes it easy to integrate with existing client-side data in Redux. It can also be expanded to work with other state-machine based solutions like ngrx. But if you don't want to use Redux in your app, you don't have to - Apollo Client will make its own internal store that you don't have to think about.

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.

Search Hashnode