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?
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.
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.
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.