Apollo on React Native Radio

Tom Coleman and I went on the December 5 episode of React Native Radio, and we got asked some really great questions. You can listen to the episode on devchat.tv, but if you don’t want to take an hour to hear the whole conversation I’ve summarized my 5 favorite parts below. Let’s dive in!

What is Apollo?

I guess before we get too deep into some of this technical stuff, for people that are listening that maybe haven’t used Apollo. What is the elevator pitch for Apollo? When you guys built this thing, what was the main problem that you were trying to solve? What’s the main draw and idea behind it? Sashko: At the end of the day it’s very simple. Our goal with Apollo is to make it easy for people to get all the benefits of GraphQL in their apps, regardless of what frontends or backends they are using. The benefits of GraphQL are so great that we don’t have to do very much on top of that. It’s just about enabling people to take advantage of GraphQL in the best way. For example, Apollo Client is a caching JavaScript client for GraphQL. React Apollo is a really popular way to use GraphQL data in your React application. The integration there is quite simple because the Apollo client core does most of the work for you. You can come in, you can say, “Okay, I don’t like the way it does Optimistic UI, and I’m going to replace that part.” Then you have essentially your own GraphQL client that does what you need. Or you can integrate with Polymer or Angular or Ember, or any other framework that you like. The idea is it implements the core stuff that’s really useful and then you can customize from there to get what you need. On the server it’s a lot more JavaScript focused. The server-side tools we’re building are just some layers around the JavaScript reference implementation, but just make it easier to describe your schema, or set up a server, things like that. Tom: Our specialty I suppose is primarily JavaScript, given that we’re a dev tools company that build a JavaScript framework, but it’s not exclusively that. For instance we now have a client for iOS that we’ve been building, just because there wasn’t really a complete iOS client out there for GraphQL that people were commonly using, so we saw a need for that and so invested a bunch of time in getting that going. That’s really the focus of Apollo, is just making it easier for people to get going, as Sashko said, especially in the open source world. It’s about making your experience better.

Learn more on the Apollo Client home page and docs!

Apollo and Redux

Could I use Redux or any one of these other Flux frameworks with Apollo? Is there any reason why I would want to do something like this? Sashko: It’s even better than that. Apollo client is built on top of Redux. Basically everyone’s who’s building React apps is using Redux to manage their data. That was one of the things we were missing when we started, is the way to integrate that with GraphQL. That’s actually where Apollo Client started from, the idea that using Redux with GraphQL should be really powerful and intuitive. The way Apollo client works is you can use it without thinking about Redux, you just initialize the client and it just works, but you can also attach it to an existing Redux store. You get the benefit of being able to look at the Redux dev tools. You can see exactly where your query results are coming in, and how they’re being recorded in the store alongside your client data. It’s really natural to use your Redux data as input into your query results. It’s actually designed especially for people who like the insight into their app data that Redux gives you, and people that are already using Redux in their app. That’s so cool. I’m so glad that I asked that question. Sashko: We saw a billion questions on the internet that were like, “How do I use Redux for GraphQL?” It’s silly that there wasn’t a first class way to do that, because everyone is using Redux and everyone wants to learn about GraphQL. They should go together, because they’re the two most popular data related things right now, so yeah I’m really fond of that.

Learn about integrating Apollo with an existing Redux store in the docs!

Server-side rendering

One other question that I want to ask is, since we’re talking about the Redux and components. In my current job I have to do a lot of server site rendering, and I’m just wondering if I start using Apollo, do I have to do any configuration or it comes out of the box? Tom: Yeah, that’s actually something that we have in the React integration of Apollo client. There’s a function in there called renderToStringWithData. It basically just calls React render to string, but before doing that it walks the tree, figures out which queries you need to call, calls them, waits for the data to come back, and then renders the string. So in a sense I guess you don’t have to really do anything beyond write one line of code that calls it. In general, in my experience, you don’t really need to change the way that you wrote your components, it should all just work out of the box. Like any isomorphic thing there can be caveats and stuff, but I haven’t seen any problems with SSR in Apollo client itself. Sashko: One other cool thing I wanted to add to that, because all of the data is stored in Redux, the way that you do server hydration is identical. You just serialize the contents of the Redux store and then put that back in on the client. It also works with some of these other libraries that help manage Redux data. They work out of the box, because it’s just regular Redux stuff. Tom: And some users that generate their HTML on the server outside of Node, for instance some Rails users, have also been able to inject hydrated data, which is really cool.

Read about React-Apollo SSR in the docs.

Future plans for Apollo

Nader: What are you guys working on now and what do you want to introduce into the project in the near and far future? Sashko: I am really excited about this because we only very recently got to the point where we’re really comfortable with the set of features Apollo Client has as a GraphQL client. We have high standards so for us stuff like server-side rendering was included as a base level feature that we wanted to have. The next step we’re working on is sugar on top you might say. The first thing is working on performance, so benchmarking in our own apps, what can we do to squeeze out a little bit of extra performance here and there, or to find out if it’s even a problem. I think it’s particularly something that people might care about on really slow devices like mobile. React Native might be running on some really old device and in that case, we’re not really sure yet exactly what the characteristics will be. The other thing is just things we’ve never really seen done before. One thing in particular I’m really excited about is having something like an Apollo dev tools. There’s the Redux dev tools for example which gives you some insight into your redux store. I think it’s one of the most exciting parts about using redux, is that you can see exactly what’s going on in your app. Because our redux store and our actions are much more meaningful, we know exactly what action it’s going to be firing, what they mean. We can build an experience on top of that, that will show you exactly what data from your server is cached, let you run GraphQL queries inside Chrome against your client store, tell you what queries are attached to which UI component and when they’re re-running and why and how often UI is working. We think we can build some really great tooling that will help people understand even more about what their app is doing at any given time.

(Editor note: The dev tools we were talking about were built as part of our company hack week and released a week ago!)Apollo Client Developer ToolsGraphQL debugging tools for Apollo Client in the Chrome developer consoledev-blog.apollodata.com

Tom: Yeah. The other thing that I wanted to mention that we’re looking at in the larger context is investigating if there are ways to make it even easier to get started, especially on the server. It would be great to have, at least for that first exposure to GraphQL, a way to just get something up and running really quickly, start building your frontend, and start playing around with what your schema might look like. We’re big proponents of what we call GraphQL first application development, which is basically where you start with your schema.

Once you’ve done that you can start building your frontend and backend in parallel, so figuring out a way to really make it really easy to stand up a schema and start playing with it, and have a server that serves it, but without necessarily having to properly implement the server in a production way could be really fruitful, so something we’re investigating at the moment. I think it would be really cool.

Is GraphQL incrementally adoptable?

For anyone listening that might not be familiar enough with GraphQL in general, is this something they can pick up and attach to the their existing Rest API database implementation, or does their backend need to be rewritten to handle this type of technology.

Tom: GraphQL is definitely something that you can add on, both on the frontend and the backend. For instance in the Node world, if you’re using Express you can just add a new route, typically called /graphql, which will serve GraphQL queries. You can continue to serve all your old endpoints, and you may continue to do that indefinitely. There’s no reason you can’t use Rest and GraphQL side by side. On the server you have GraphQL resolvers, which are the functions that get called to figure out what the result of a query should be. They can go ahead and call any other function in your backend. Typically they should be pretty thin and they should go straight to your model layer, where all of the logic should live.

Typically your REST endpoint handlers and GraphQL resolvers will look pretty similar, and they both just call out to a model somewhere with some arguments. They don’t do a lot of logic.

On the front end you can definitely start using GraphQL while continuing to do whatever it is that you were doing before to get data. You could have one part of your site which uses Apollo or Relay to fetch data, and attach it to one sub-tree of your React rendering tree, and the rest of your tree might use data that’s been fetched into Redux via REST or whatever other mechanism you have fetching data.

There’s really, absolutely no reason why you shouldn’t do that. In fact that’s what a lot of people do and do it very successfully. Our hope would be that over time all of your app would become GraphQL or Apollo, but of course that going to depend on what makes sense for you and what works best.