Choosing a GraphQL Client: Apollo vs. Relay

Apollo and Relay are currently two of the leading open-source GraphQL clients for NodeJS apps.

If only there was a quick and easy side-by-side comparison so you could make an easily informed decision on which client is right for you. Well, congratulations, you found one!


Why choose a GraphQL client?

Of course, before making such an important decision, we should discuss why we even need a GraphQL-specific client. Why can’t you just stick with whatever you’ve comfortably been using? Redux, for one, happens to work fine with GraphQL. If you’d like to spend more time simply figuring out how GraphQL works within a more familiar context like Redux.

However, Redux isn’t designed to maximize the benefits of GraphQL. If your goal in learning GraphQL is to really take advantage of its amazing benefits, it makes sense to also invest in a client-side technology that aims to get the most out of your GraphQL server.

To this end, Apollo and Relay both implement query and data caching in some form to further optimize requests to the graphQL server.

This means doing lots of pre/post-processing to make “smart” requests, which Redux isn’t built to do for you. Apollo and Relay also do lots of other nice things. Instead of reading an entire compare/contrast essay about said things, here’s a neat table below.


Comparison

Apollo and Relay share many features, but they’re clearly not identical. So, here’s a breakdown of how they’re different. In order to keep this brief, I’ve included links to what I believe are good resources for more information.


Key Values

Apollo:
  • Incrementally adoptable
  • Simple to get started with
  • Inspectable and understandable
  • Built for interactive apps
  • Community Driven

Relay:
  • Declarative: what data, don’t worry about how or when
  • Colocations: write data dependencies right in the view
  • Mutations: data consistency, optimistic updates, and error handling



Object Identification for Caching

Apollo: __typename + id (client-side, automatic)
Relay: graphql-relay globalId (server-side, requires GraphQL schema configuration)

Query Language

Apollo: graphql-tag
Relay: Relay.QL

Query Batching

Apollo: built-in (one-line setup + config)

Subscriptions

Apollo: yes
Relay: yes(ish)

Fragments

Apollo: yes
Relay: yes

Optimistic UI Updates

Apollo: yes
Relay: yes


Pagination

Apollo: Arbitrary pagination schema (server-side), fetchMore (client-side)
Relay: cursor-based (server-side, requires GraphQL connections configuration)


Custom Network Interfaces

Apollo: yes
Relay: yes


Server-Side Rendering

Apollo: yes


Performance (Caching and Query Optimization)

Apollo: yes
Relay: yes


Routing


Testing

Apollo: Jest (assuming you’re using React)
Relay: Jest


Developer Tools

Relay: React DevTools - (chrome extension)


Compatibility

Apollo: React, React Native, Angular 2, Redux, Meteor
Relay: React, React Native


Learning Curve (Familiarity)

Relay: new material


Mutation-Writing Complexity

Apollo:
  • Simple GraphQL mutation w/ resolve
  • Send literal mutation through Apollo client
  • Update Apollo client store
Relay:
  • GraphQL mutation w/ mutationWithClientMutationID
  • Match variable names between GraphQL and Relay
  • Set up fat query & configs for Relay


Documentation

Apollo: fantastic, with pictures!
Relay: ...spotty


Open Source Stats*

  • Watchers: 87
  • Stars: 815
  • Forks: 61
  • Pending PRs: 9
  • Commits in last month: 176
  • Watchers: 339
  • Stars: 6,940
  • Forks: 576
  • Open Issues: 123
  • Pending PRs: 10
  • Commits in the last month: 10
. . .

Ultimately, it comes down to you and the specifics of your project. Apollo offers a friendly developer experience and works great for learning and adopting GraphQL into an existing project, especially if it doesn’t use React. Relay is being built with mobile performance and scalability–at the Facebook level–in mind.

Never miss a post from Ritesh swamy, when you sign up for Ednsquare.