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