GraphQL with Redux

In this talk, Michael Langmayr talks about how GraphQL and Relay can enhance data fetching in your client-side applications. He also makes the case for replacing Redux with Relay and touches on why Facebook felt the need for another data store technology.

Watch the video on YouTube below and enjoy ?:

[00:00:07] Hello everybody, so this talk is actually related to the talk you heard before, because apart from the fact that I’m going to be talking about GraphQL, the system is the same so we are also doing asynchronous calls and we’re going to store them in a Redux store, there are loads of them. Myself, I’m Mike Langmayr, I work at BT and it’s an awesome company and we’ve been doing React for a number of years now. I’m glad I joined here. The basic React and GraphQL stack that people are used to is that. This is how it was introduced, in January, 2015. It was basically React and GraphQL and Relay as the link. Basically, it’s a client caching layer that basically stores the results that you get from GraphQL and it lets you query those results in a declarative way. The only thing that’s changed since then is Redux became pretty popular. I want to explain why a lot of people in the community are replacing Relay with Redux now. It looks like this for a lot of people who work with GraphQL these days.

[00:01:43] What is GraphQL? GraphQL is a lot of things actually. It’s a whole framework but mostly it’s a data querying language that is based on JSON, it is server side technology, so if you want to make use of GraphQL, you need to have a server that supports it but there’s support for all big server side technologies for Java, Ruby, PHP, even Node, so you name it. Facebook invented it because it had a lot of problems with calls using react on mobile devices and React native, so it was looking for a solution where it has to make the minimum number of calls and get exactly the data out that it wants, so not more data and them trim it down in the client because that’s inefficient. Can you guys read this? This is what the syntax of GraphQL looks like, it’s basically JSON and when you make a request, you basically give a JSON object with an ID and the properties that you want and the response is the same object, including the values. It’s very simple and for every JavaScript developer, really familiar.

[00:03:12] Advantages of GraphQL are that you only need a single endpoint. Everyone who has had the experience where you have a frontend team and a backend team working together and the frontend team needs a new set of data and the backend has to write a new API. This whole thing would be cut out in this scenario, so you can basically query all the data that you need from the server in the client, which is really great if you’re a frontend developer. You can specify exactly what data you want. Inside the client, you can say, “I only want this set of properties”, you can do pagination much easier, and you never have that situation where you get way too much data from the server and then you have to filter it or something like that, you always get exactly what you want. Co-location of queries and the view code is something that is useful if you manage the data. I have an example here. Again, I hope you can read this.

[00:04:22] It’s basically you use in the lower section, there’s a bit of JSX there, so you basically write out the user name and then the top section you request the username. If you would need any other property from the user, you would just add another property and request it and it’s that easy. I think that is a pretty good thing that speaks for GraphQL. Then Relay is what I mentioned earlier, it is that framework that Facebook originally sought out to be used for GraphQL. It’s a data fetching framework, it does more than just request GraphQL data for you, it also caches it for you and is inspired by Flux. When Relay was created, there were still Flux implementations that had multiple stores and all those problems, so people thought, “Why don’t we make a solution where we have one single store?” Kind of like Redux is now, “But just for server side data”. Uses container patterns. Whenever you want to hook up a React component with data, you basically create a Relay container and tell the container what kind of data it wants and then put all the components inside.

[00:06:05] Yes, components are re-rendered when data changes, I think a lot of people are used to that from Flux anyway. That’s a bit of a caveat that it’s only for server data. It’s not like a Flux store where it can just put anything inside and manipulate it whenever you want to, it is those declarative queries that you use to query a server. The same way you query the Relay store. The Relay store will decide for itself if it needs to query the server or if it gives you the cached version. It works mostly with React; whereas, Redux is independent from frameworks, at least in theory. Relay has mostly been used with React and there are some projects that try to use it elsewhere, but I don’t think they have gotten very far from what I’ve been seeing. Then what is Redux? Does anybody here use Redux? Professionally. That’s still quite a good number. Yes. It’s good, I think, I love Redux, I’m glad it’s spreading. It’s basically an implementation of Flux but it just uses one store. It basically uses reducers to take all the stores that you used to have in the Flux patterns and reduce them into parts of one store object. It makes it really nice to see what state your application is in at the moment.

[00:07:39] It’s encouraged to use a container presentation components pattern where you have some components that basically look nice and do the things you want, and container/components that are linked to data. It has great React integration, of course, but you can use Redux in Angular 2 for example and in other JavaScript frameworks. This is a graphic how Redux typically works, where you have the Redux store and then you have the view component and it dispatches an action and then it goes to the reducer and then back into the store. The store re-renders the component, so pretty much like Flux anyways. This is how it would look like if you used GraphQL with Redux. You would use an asynchronous library, one like Chris mentioned earlier, I’m using Redux-thunk at the moment and all you do is you start an asynchronous call, but to a GraphQL endpoint and you send your GraphQL query and then the response that comes back, you reduce it and put it in a Redux store and re-render your components.

[00:09:10] Caveats. There are some, of course. Like I mentioned earlier, Relay is more than just a data-fetching framework, it is a cache. You’re missing out on the caching that Relay does. Relay has some really cool features, so for example, if you want to do pagination, it does that out of the box. If you don’t use it, you’re missing out on that too. Relay has really good React integration but I mentioned that earlier. There are projects like cache, for example, which is a client-side GraphQL cache, which does a lot of the things that Relay does. I don’t think it’s as advanced yet but I’m sure it will get there, as I think the community is moving to use Redux instead of Relay. That’s it. Thank you very much.