We wrote this summer about our move to React and GraphQL at The New York Times. At the time, we were using Relay, Facebook’s open source GraphQL client. We recently shipped a refactor of our app to production using another GraphQL client: Apollo.
Apollo is being used by our web frameworks team and by a number of our feature teams. It is changing the way we build the reading experience for our users, and it gives our developers more tools with which to create.
What about Relay?
Facebook rewrote Relay and released it this summer as Relay Modern. We took a deep look at it, which Scott Taylor wrote about here. And while Relay Modern is a good option for many teams, there are some important differences.
- First-class support for server-side rendering
Server-side rendering (SSR) is a hard requirement for our site. There are important SEO considerations, as well as performance benefits like First Meaningful Paint (FMP). Relay takes a “bring your own solution” approach to this problem. In Apollo, SSR is a first-class feature. This is huge for us.
- Routing agnostic
Relay Classic and Relay Modern do not ship with a router — you must bring your own. The open source community around Relay does not leave us with many options. Apollo is router-agnostic, which means we have choices and can pivot, if necessary.
While we were using Relay Classic, Jeremy Gayed took an early look at Apollo. In his post here, he explained that it was clear there were a number of long-standing issues Apollo could help us solve.
From an end-user perspective, there is little difference. However, from a development and product perspective, Apollo unlocks future platform improvements that we’re really excited about:
- A more vibrant ecosystem: It’s important for the Times to bet on tools that are part of an active and engaged community.
- Better server-side rendering/isomorphic support : This includes fine-grained control over where and when queries are fired. We can delay some queries until elements are scrolled into view, and we can isolate others to fire only on certain device types or viewports.
- Preloading/prefetching: With Apollo, we can selectively prefetch certain queries for a snappier reader experience.
- Code-splitting at the component level: This was difficult to do before, because of the static routing requirement with Relay.
- Apollo Link architecture: Middleware for the GraphQL fetching layer using Observables.
- Modeling local app state as part of the schema: In some cases, this may obviate the need for Redux.
- Schema stitching: This allows us to seamlessly connect to multiple GraphQL backends and treat them as if they were one.
- Persisted queries: We can now send a query ID instead of the full the query over the wire.
- Enhanced debuggability and local developer experience: We now have tools to monitor Apollo inside Chrome DevTools.
The Apollo team has been helpful and responsive throughout our migration, even publishing two package upgrades as a result of our direct feedback! We are grateful for their support and excited to build out new experiences for our readers.
Want to know more?
Watch Scott Taylor’s GraphQL Summit keynote.