I am writing a React GraphQL book which I intend to release the next months. If you are interested in following me on this journey or grabbing a copy of the book as one of its first readers, you can opt-in for receiving updates about it. Feel encouraged to leave me any feedback for improving the content. You can even contribute to it by editing this article on GitHub. After all, I want to produce a high quality book which should enable people to learn about GraphQL in React similar to The Road to learn React.
The following topics show you the major advantages of using Apollo.
The Apollo ecosystem offers plenty of solutions for many problems even though GraphQL is in its early stages. And the ecosystem is growing. At every other conference the company is announcing an update for Apollo or another library which can be used complementary to Apollo’s tech stack. For instance, that’s why Apollo is not only covering GraphQL but also REST interfaces for enabling backward compatibility to RESTful architectures. It goes beyond GraphQL being used only for the network layer and remote data by offering a state management solution for local data too. So if you make the leap to use Apollo for your application, you are welcomed with a great ecosystem.
The Company and Community behind Apollo
Who is using Apollo?
Even though Apollo is evolving all the time, the team and community behind it makes sure to keep the documentation up to date. Going through their documentation should give you plenty of insights into how you can build your first application with Apollo without reading up any third-party resources. They cover so many areas that it can be also overwhelming for a newcomer. So make sure you go through the content topic by topic and apply it in your own application.
For instance, the former can be seen with Apollo Link which provides you a API for chaining different features into your GraphQL control flow. It makes it possible to enable automatic network retries or to use a RESTful API endpoint instead of a GraphQL endpoint (whereas both can be used together too).
The latter fact, saying Apollo is offering exchangeable libraries, can be seen for instance by looking at the Apollo Client Cache. Apollo Client itself is not opinionated about its cache where the data is stored. You can use any cache which is advertised by Apollo or its community. That’s why there are already a few caches out there which can be used to setup a Apollo Client instance.
Apollo comes with plenty of built-in features which are not simple to implement yourself. Therefore you are able to pull all the complexity out of your applications and leave the intersection between client and server application to Apollo. For instance, Apollo Client makes sure to cache your request (requests are not made twice when the result is already in the cache). That’s a great performance boost for your application, because it saves valuable network traffic. In addition, Apollo Client normalizes your data. Hence when receiving nested data from a GraphQL query, the data is stored in a normalized data structure in your Apollo Client Cache. Hence you can read data from the Apollo Client Cache by an identifier and, for instance, don’t need to look up a “article” entity in an “author” entity. The article is referenced by its identifier in the Apollo Client Cache. Apart from caching and normalization, Apollo Client comes with much more features such as error management, support for pagination and optimistic UI, prefetching of data, or connecting the data layer (Apollo Client) to the view layer (e.g. React).
Interoperability with other Frameworks
Apollo is not only on the client-side library agnostic. Also on the server-side for Node.js it offers several solutions to connect to different Node.js libraries. Whereas Apollo Server for Express.js is the most popular choice among developers and companies, there are other solutions for Koa and Hapi on Node.js for Apollo Server as well.
Modern Data Handling with Apollo
Do you remember the cases where you had to trigger data fetching in one of your component’s lifecycle methods in an imperative way? These times are over with Apollo Client, because you query your data in a declarative way with Apollo Client. Most often you will use a higher-order component or render prop in React which triggers a query automatically when rendering the React component. Only the GraphQL mutations are triggered imperatively, but only because a higher-order component or render prop gives you access to the function which executes the mutation (e.g. on a button click). Apollo embraces declarative programming over imperative programming.
Modern State Management with GraphQL and Apollo
Convenient Development Experience
The following topics show you some of the disadvantages of using Apollo. It is not my intention to put Apollo in a bad light here, I love to use it myself, but I want to give you a well-rounded pro and contra list of using Apollo. If you think that anything should be improved in this section, or in the other sections, please reach out to me.
Since GraphQL is in its early stages, everyone, not only Apollo but also other early adopters, are working on a bleeding edge technology. The Apollo team is eager to develop a rich ecosystem around GraphQL, not only providing the basics, but also offering advanced features such as caching and monitoring.
However, this comes with the pitfall that not everything is set in stone yet. Here and there you will have changes, especially because Apollo is moving fast, and you have to deal with them when updating your GraphQL related libraries. But the Apollo team is doing everything to keep the breaking changes to a minimum. In contrast, other libraries in the GraphQL space may be more conservative here, but then again they don’t put out so many powerful features as the Apollo team is doing it.
Another aspect is the learning experience which is affected when everything is evolving so fast. For instance, tutorials for GraphQL in general, but also Apollo, happen to be outdated and you have to look up other learning resources. However, most of it doesn’t apply only to Apollo, but also to other open source projects in this space and perhaps to programming tutorials in general.
The Apollo team and community works eagerly on implementing many new features in a rapid pace. But going so fast comes always with a price. For instance, when searching for a solution when running into a problem, you often end up in a GitHub issue, because there is not much other information about the problem out there yet. After all, you can be happy to stumble upon something at all. However, even though there is a GitHub issue for your problem, it can happen that there is no solution for your it yet.
Going at a rapid pace always comes with the price of neglecting old things. As I have experienced it, people seemed confused when Apollo abandoned Redux as their internal state management solution. Apollo isn’t opinionated about how Redux should be used side by side with it, but since it has been abandoned as internal state management solution, many people didn’t know how to proceed with this new information when Apollo 2.0 got released. After all, I think the team behind Apollo has just too many things on their plate, they are struggling as well to keep up with the fast paced GraphQL ecosystem, and it’s not always easy in open source to listen to all the voices out there. So maybe that’s just your opportunity to help them out by contributing to their open source libraries.
It is Bold and Fashionable
Apollo is fashionable, because it keeps up with the latest trends. In React the latest trend were render prop components. Because of this trend, and arguable several benefits of having render prop components over higher-order components, the React Apollo library introduced render prop components next to higher-order components. Overall it’s a great move to offer multiple solutions, because both concepts, higher-order components and render prop components, come with their own advantages and disadvantages. However, Apollo advertises render props over higher-order components and it is not too clear whether this was hype-driven development and a marketing move or whether they truly believe that this is the preferred way to go in the future. Render props are fairly new in React and it will take its time (again) that people realise that they come with their own pitfalls (see higher-order components). Personally, I have seen React applications which ended up to be too verbose by having multiple render prop components in one React component, even though one render prop didn’t depend on another render prop, rather than having those co-located to the React component by using higher-order components. After all, Apollo offers both solutions, render props and higher-order components, and again it is up to the developer to decide on a case by case basis for their applications, because there is no silver bullet to it. In the end, it is great that the Apollo team is keeping up with the recent trends from other libraries out there. They are not just hanging in their own bubble, but communicate to the folks developing other libraries concerning the Apollo ecosystem.
Apollo Client Alternatives for React
When it comes to Apollo Client for React, Angular, Vue or something else, there are several alternatives you can checkout. Obviously these come with their own advantages and disadvantages whereas these things are not covered here.
plain HTTP request: Even though sophisticated GraphQL libraries can be used to perform your GraphQL operations, GraphQL itself isn’t opinionated about the network layer. So it is possible for you to use GraphQL with plain HTTP methods by having only one endpoint with an opinionated payload structure for GraphQL queries and mutations.
Relay: Relay is Facebook’s library for consuming GraphQL on the client-side in React applications. It was among the first GraphQL client libraries before Apollo emerged.
urql: urql is a GraphQL client library from Formidable Labs for consuming GraphQL in React applications. It was open sourced as minimalistic alternative in contrast to the growing Apollo behemoth.
Apollo Server Alternatives for Node.js
When it comes to Apollo Server for Node.js with Express, Koa, Hapi or something else, there are several alternatives you can checkout. Obviously these come with their own advantages and disadvantages whereas these things are not covered here.
- express-graphql: The library provides you with the lower level API to connect your GraphQL layer to your Express middleware. It takes the pure GraphQL.js reference implementation for defining your GraphQL schema whereas Apollo Server builds up on top of this to simplify it for you.
Did the article help you? Share it with your friends on social media , support me on Patreon, become a React developer with my books
Build a Hacker News App along the way. No setup configuration. No tooling. No Redux. Plain React in 190+ pages of learning material. Learn React like 33.000+ readers.Get the Book