Apollo Client 0.8

In my last blog post I wrote about how Apollo Client had passed feature parity with Relay and was ready for production use. In the three months since, Apollo Client has become a lot smaller, faster and better thanks to hard work from our engineers and the projects’ many open source contributors. Apollo Client even has its own developer toolsnow! All of this makes me very excited and optimistic about the future of Apollo Client and our plans to make it even better.

In this release, we focused on three things:

• size
• speed
• simplicity

The goal is to make Apollo Client the fastest, smallest and simplest caching GraphQL client. To get there, we’re simplifying the core and making it incredibly fast. On top of that, we’re making Apollo Client modular so it will be easy to get just the functionality that you need in your app without any extra weight.

Why are we doing all of this?

1. We believe that data loading shouldn’t get in your way when you’re building an app. It should be simple, fast and work out of the box.
2. Page load times and fast UI really matterwhen it comes to user retention. Amazon found that just a 100ms increase in page load times cost them 1% in sales!

Now that you know what we’re trying to do, here’s a quick overview of the most important improvements, bug fixes and stats for Apollo Client 0.8.

Apollo Client 0.8 is smaller…

• By removing lodash, Caleb managed to bring the gzipped bundle size down to 23.6Kb. We’re working on making it even smaller by removing more dependencies and refactoring some of the larger modules. All of this was made possible by a PR from community member Jayden Seric. He added a script which let us analyze the bundle size and produce these cool visualizations:

• Thanks to a PR by Kamil, Apollo Client now supports tree shaking and code splitting, which means that your app will be even smaller and load even faster if your build process is set up for it. You now have the choice between AMD, CommonJS and ES6 modules when you bundle Apollo Client. If you’re not sure what those are, read this excellent post on the topic.

faster …

• Since 0.7, Apollo Client returns referentially equal results when parts of a query result haven’t changed. That means that if you’re using it in a React component, you can use triple equals (===) instead of doing a deep comparison in your shouldComponentUpdate to check if the props have changed. That makes your app simpler and can speed up your UI a lot.
• Apollo Client has also gotten smarter at figuring out when it needs to re-run a query against the store, and it no longer does so when an external Redux action did not affect the Apollo part of the store.

better …

• We’ve introduced a new fragment syntax and deprecated the old one. You can now declare fragments anywhere to share them between modules, use them to generate prop types, and even to filter props for components. This was the main feature people said they missed from Relay, and now you can use it in Apollo!
• We’ve added support for GraphQL null input values and optional arguments.
• To make Apollo even better for our TypeScript and Visual Studio Code users, we turned on strict null checks, updated typings Apollo Client depends on, and added generic types to queries and mutations. That means you can now get type safety for your GraphQL results. Special thanks to Brett Jurgens for the PR!
• We’ve also added a more flexible way to refetch data after a mutation returns. Instead of referring to the refetch query by name, you can now provide the query and variables directly, giving you a lot more freedom to handle things the way you want.
• We’re now deep freezing query results in development mode to prevent developers from accidentally modifying the result object, which is supposed to be immutable.

We’ve also fixed a few bugs …

• We fixed a sneaky bug that led to store inconsistencies after optimistic updates if a certain race condition occurred.
• We’ve added code to make Apollo Client handle invalid server responses more gracefully.

and did some refactoring …

• We’ve changed the way Apollo Client calculates the loading state of a query and aligned it with networkStatus, probably killing a few bugs in the process.
• We’ve removed an undocumented feature in preparation for rewriting the way we update the store after a mutation. I’ll write more on that in a future blog post.

---

We wouldn’t be where we are today without our amazing community of contributors. In the last three months you’ve helped us merge over 200 PRs and close over 200 issues on GitHub. Thanks for being awesome!

Do you want to become an open source contributor? We’re always looking for more contributors to work on cool GraphQL projects like this one. Make the first step today by joining our Slack channel, filing an issue or making a pull request!

Our first-ever Contributor Week is starting on Feb 7th 2017, so if you’re new to Open Source, GraphQL or Apollo, that would be a great time to get started!

Our top priority is to build the GraphQL client that developers need, so if you have ideas, suggestions, or time to contribute, we want to hear from you. Please fill out this survey to help us improve Apollo Client:

Click here to fill out the survey

Thanks for helping us make Apollo Client more simple and elegant!

Made it all the way down here? You must be really interested in GraphQL or Apollo! Did you know we’re hiring?