The focus of today’s episode is GraphQL. The team break down the language and how it might just be the way to go for the foreseeable future. Dave shares much of his experience and opinions on using GraphQL and we look at how it can fit into the rest of your operations.
During the show we also look at instances in which GraphQL may not be the best query language and why this may be. In addition to the usual teach and learn section, we give you the best overview of GraphQL, covering all angles and imagining its utility in different settings. So, let’s get into it!
Key Points From This Episode:
Transcript for Episode 52. Is 2018 the year GraphQL kills REST?
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:13.7] MN: Today we’ll be talking about whether, it’s 2018, the year of GraphQL and will it kill Rest once and for all.
[0:00:21.9] DA: So much hype.
[0:00:23.1] MN: So much hype, killing involved and Rest, is it finally going to be put to rest, pun intended.
[0:00:30.5] DA: Wow.
[0:00:31.5] MN: Yes. Episode over, done. We’ll talk about GraphQL, some of the theories behind its creation and then we’ll talk about some best practices and the practices behind it.
[0:00:45.2] WJ: The way in which we think the adaption of GraphQL is going to “20-accelerate-een”.
[0:00:51.4] MN: “20-accelerate-een”. Nice, it’s happening.
[0:00:56.2] DA: Yeah, I mean, like, for so long, Rest has been like the standard for how you got data from one place and put it in another place. Often, you know, the backend of your application from your database to the front end but it’s interesting, a lot of people are kind of rallying against that now. I saw a pretty opinionated blogpost recently, asking a question like “Is rest the new Soap?” Just like going that rear and be like, you know what?
The rest promise so much but actually, it’s just like, it’s just as bad as XML and like all of the other things that’s Soap going for it.
[0:01:32.6] WJ: Definitely not that bad.
[0:01:35.8] MN: Yeah.
[0:01:38.0] DA: Probably not.
[0:01:39.1] MN: Let’s start with defining what is GraphQL or as I read it, GraphQL or what’s the cool – what’s the way that people normally say it so we can now get this right once and for all.
[0:01:49.8] DA: Just GraphQL.
[0:01:50.7] MN: GraphQL.
[0:01:51.6] DA: It’s query language, that’s the QL part and it’s resolved in a graph of data so as supposed to like, Rest where you have a single end point that represents an object. You can get all of your objects in a single query or much like a sequel query where you can now join some all that crazy stuff.
Yeah, but GraphQL is just a standard. Facebook has been developing it internally since 2012 and they open sourced it two years ago and since they open sourced the standard and a reference mission Java Script, just blown up. An information pretty much everything language that you don’t want to program something in.
[0:02:34.8] MN: It makes the retrieval of data easier because you don’t have to hit a specific endpoint to get specific data, you can actually request a map of information and then get that back if necessary, is that the idea?
[0:02:51.1] DA: Yeah, it kind of like – improves the developer experience where you just have one endpoint now and the end point is smart and knows the connection between different pieces of data through a resolve or function.
It’s like, “Okay, this field, if I need to get this filled, this is how I’m going to go fetch it.” I’ll go to the ORM, I’ll get this data, I’ll pass it through and then maybe that field has like other fields inside of it you know, if you have like a post with your author and you want to get the author’s name, maybe like the author’s a different thing so you get the post and you get the author and then you get the name from that.
[0:03:28.9] WJ: It’s like, if you wanted to get the author and the blogpost using Rest, you’d have to hit two end points or maybe like hit a deeply nested endpoint and a back end engineer or somebody who maintains the API code base, would have to go and make a new endpoint if that was the first time you’d done that before.
Whereas with GraphQL, you can say, “Well you know, I just want a post and I also want a list of all the authors associated with it.” And maybe just do that for you.
[0:03:59.1] DA: Maybe like a Rest end point if you ask for an author, you might also get there like date of birth or what their favorite color is and other kinds of data that I just don’t care about, I just want the name and I just want to know Bobby wrote this post and I don’t need integrated data. GraphQL gives you away to avoid over fetching data like that.
There are ways to do that with Rest but it’s not standard and it’s not often something that you see in a Rest endpoint.
[0:04:28.7] MN: What I’m hearing, one of the benefits is that you can get, you can post and put exactly the things you want to get or post or put?
[0:04:40.3] WJ: Yeah, it’s like it lets you build the API like on the fly, whenever you need it from the front end, you don’t have to touch the back end code.
[0:04:48.2] DA: Yeah, we’ve talked about queries, the query part of it, but for posting and putting, actually with GraphQL everything mostly, depending on the implementation server it’s going to be opposed. You don’t have like the verbs or the error codes of rest which relies on HTP, kind of backing you up, you post it and then you get a 200 and then it has the information like there or the fields you’re looking for.
If you’re trying to like change data then there’s this concept of mutation where you apply like a named operation like I’m going to add an author to my post and from that named operation it will pass in the data, you know, this is the name of the person, this is our favorite color and I’ll give it like a list of fields that I want back like a query inside that.
What that allows you to do is to have like a really smart client that can update its cache locally after you do a mutation and yeah, just makes it a bit easier for developers.
[0:05:52.9] MN: What are some of the advantages that you get by having this new type of framework to retrieve data?
[0:06:02.2] DA: First of all, we’ve mentioned earlier like you avoid over-fetching, you only get the data that you want, when you want it. Secondly, GraphQL is typed so like every field that you get back, you know that it’s going to be a string or a number. You know if the field could possibly be empty or null.
As a result of that, you can kind of have a smarter client that handles things for you, a better dev-tool experience that uses that stuff, there’s a pretty sweet tool for like GraphiQL that sounds like GraphQL but there’s little I in the second there. It’s like an interface for like writing and query and there’s like query completion, you can look at all the documentation and explore the schema. Pretty nice developer experience for that.
[0:06:53.3] MN: Are there any tools that developer can use to further enhance the GraphQL experience?
[0:07:01.1] DA: I mentioned one GraphiQL which is a tool to help you explore the data and queries and get auto completion. There are some other tools like GraphQL voyager which will take your schema and kind of zoom around and see the connections between the different types and you know, visually see what the connection between things are, that’s a pretty nice one.
There’s also tools for like mocking your schema so since it is a typed schema, it can reply back, intercept call so that back end and reply back with fake data, a fake name or a fake address or what have you.
[0:07:41.3] MN: You can potentially – it’s really easy to setup testing environments because you’re able to mock out any of the API calls with information that you may now want to use whether it’s sensitive or –
[0:07:54.3] DA: Yeah, basically. It still requires some work and I think we can talk a little bit more about that in depth if you want but yeah.
[0:08:03.0] MN: We’ll talk about that in practice, in the practice part of this. I mean, so far GraphQL sounds like it would be much easier for the front end developer to get whatever data necessary but when would it be a – when would you not want to use GraphQL?
[0:08:22.7] DA: It can be like kind of challenging if you have to gather data from a lot of different places like deeply nested query. You know, it can be challenging to optimize sometimes because it’s taking a lot of the things that the front end would have to do to gather all these different data from rest end points and normalize it and mush everything together and kind of push in that complexity on to the back end.
[0:08:50.5] WJ: Can you use it with NoSQL databases? I mean, it’s a graph API, it seems like you would think that there would be a way to hook that up to something like neo4j?
[0:09:01.6] DA: Actually, there is a stack involving graph database with GraphQL and it’s called a Grand Stack, GraphQL, React, Apollo and neo4j Database, that’s the D. It’s kind of a stretch but that’s one of them. But really, you can use GraphQL with pretty much anything, especially with some of the clients that have been developed for the front end like Apollo client.
There’s a really active community of people who are developing all kinds of adaptors to use GraphQL for every aspect of their lives. People are really passionate about it. Not like use it like in a more traditional way to hit a GraphQL endpoint and get the data but people are making adaptors to actually reach out to rest end points like and deal with them using queries like from the front end or deal with local state in the browser using queries as well, completely getting rid of redux entirely.
You know, when you use a client like Apollo then you no longer really need to manage as much of like the state for fetching data as you do before. You find like a lot of the code for normalizing API responses and managing the fetching inner states kind of goes away.
That’s already like a lot of – depends on redox and state management on the front end that you’re getting rid of. People are kind of going all the way with that now.
[0:10:40.6] WJ: Feels like you’re just trying to get rid of the back end all together.
[0:10:46.2] MN: Shh! Don’t let them know.
[0:10:49.4] DA: I mean, you still need the back end really because like you’re kind of encapsulating, in a way you're actually making the front end dumber if you’re using GraphQL in some ways because it doesn’t know how to gather all the stuff in the back end implements this like functional approach to resolve all the different fields and glue them together.
You’re making your front end less complicated and your back end a little bit more.
[0:11:22.5] MN: Shh! Don’t let them know we’re making them more complicated. Yeah, I imagine front end engineers would appreciate the idea of getting that information a lot easier to then do whatever necessary to display it to the user, which is happy all around.
[0:11:42.8] WJ: That’s all good in theory but how does this actually work in practice?
[0:11:46.1] DA: Yeah, I mean, that’s a good question, there’s a lot of promise to stay with GraphQL, it makes your life easier in the front end because you only have to make one request and it makes your life easier in the back end because you know, you just have to think about it in terms of a simple, functional approach to resolve in the fields.
[0:12:04.0] WJ: So what’s the catch?
[0:12:08.6] DA: I guess in the front end with Rest, if you have like kind of a – I don’t know how to say this out loud but the [inaudible] structure where you have like one resource per end point, you might have like end plus one problem where you’re fetching a lot of data and fetching related data on the front end.
With GraphQL, you’re still going to have that problem even though you only have one request, I guess you’re just pushing it to the back end. If you have a lot of nested relations then you know, you need to go to each level of that and fetch the related data and then go to the next level and so on and so forth.
[0:12:45.6] WJ: You need to drop down into Roxy SQL here in order to fix that?
[0:12:48.4] DA: I mean, you can kind of optimize your queries like this is kind of a little bit leading edge but people are writing better tooling for this but an easy way to do it is to select related tables when you’re getting data out of your ORM for earlier fields and then you can pass that down to the subsequent fields that are related.
Or you can also use Data Litter which lets you, kind of aggregate all of the request for a certain kind of information and then resolve it together so you kind of end up with less request going out to your database, you can collect it into one big blast ORM to get all the related fields.
There’s also like kind of some challenges around like the design principles of the schema, like figuring out how to make it really flexible for the front end. But also limit how flexible you’re going to make it. You can pretty much do anything. Some people like using the relay framework for writing a GraphQL back end. So that kind of gives you some specific guidelines like using globally unique IDs for the different notes and the graph, the different types that you have like your author will have a global unique ID, your post will have a global unique ID, you know, specifying connections between fields and a specific quay with nodes and edges. So that you can do the pagination and describe the relationship a little bit easier.
[0:14:18.6] MN: When you mentioned the flexibility in the front end though, the tradeoff being that it’s flexible on the front end but more complicated on the back end? Is that how it is or is it because you can literary do anything with GraphQL so you have to have some structure to make it comprehensible?
[0:14:38.7] DA: Yeah, I think going back to the M plus one thing with like all of the nested information like that’s going to be challenging if they’re resolved and figure out how to scale it like a lot of bigger companies that use GraphQL like Yelp and Twitter. They have pretty big GraphQL end points that you can use that are public, GitHub is another one and often in those cases the GraphQL is kind of a layer that glues together a bunch of micro services.
So under the hood, they may be reaching out to a Rest end point to get the data for posts and like another end point for authors and then gluing those together. Or it could be like GRVC or any other technology to get that data out but there’s different scaling concerns with that too.
[0:15:32.1] MN: I mean we all are competent developers who really enjoy testing as mentioned before in life, how does that help with testing end points and testing like your front end? I know you mentioned some, that you are able to mock data on the fly with Graph QL. How does that help developers test in the end with their GraphQL or their front end?
[0:15:57.5] DA: I mean I guess like with GraphQL you know what the shape of the data is going to be because it is just going to be JSon coming into your application. So that’s pretty easy to mock out and pass into your components like in React as you would pass it through when you are testing something that’s connected to Redux and on the back end, your resolver function is just a function. So there’s some known inputs and there’s an output.
So there is a nice paradigm for testing that as well. And also related to testing, since it is statically typed, the backend has a scheme that is going to implement with some shape and types and the front end has some queries that it is going to ask with some shape and those fields have types and so it is easy to do kind of a linting against those two to say, “Okay is there any expectations that are not met between the front end and the back end?” And have a contract test between the two.
[0:17:03.4] MN: Yeah no. That sounds awesome. Everything sounds very great with GraphQL. There has to be some disadvantages, there just has to be. It sounds amazing, everyone would just stop using Rest because we should kill it for 2018. But what are some of the disadvantages in GraphQL that you may see may appear to developers and engineers who pick up this new piece of technology?
[0:17:28.8] DA: Yeah, I mean it’s pretty bleeding edge. So when you are working on like optimizing something, it can be challenging to find the right reference or tooling to do it. People are developing it all the time. It’s kind of exciting because the opportunity that you can contribute back to the community but you have to be the expert in a lot of situations. You know there is a learning curve although once everything is in place, it does make your life a lot easier. You know getting started can be a little bit tricky.
[0:17:58.4] MN: Cool, we just went through a conversation on GraphiQL, GraphQL, Graph Q, Graphcool, GraphQL. It’s just don’t be –
[0:18:07.5] DA: Graph Cool is a thing.
[0:18:08.6] MN: Yeah, GraphQL, we just had a conversation about GraphQL.
[0:18:13.9] WJ: Well hang on a second, Graphcool is a thing?
[0:18:16.0] DA: Yeah, it’s a server-less GraphQL.
[0:18:18.4] MN: Yo I thought I was making that up. I’m obviously not that innovative.
[0:18:23.1] DA: I’m ahead of you, this is the bleeding edge stuff. Graphcool is a server-less GraphQL, check it out.
[0:18:28.0] WJ: Have you heard of Graph Quizzle?
[0:18:29.1] MN: Oh Graph queezy!
[0:18:30.7] WJ: Please tell me that is a thing.
[0:18:31.7] MN: No, it’s going to be.
[0:18:32.6] DA: That’s open on the MPM bit name’s phase like Quora.
[0:18:36.8] MN: Yeah, William make sure you got that and we’ll think of something afterwards. We get it and then we’ll build something later. That sounds so exciting. Awesome, before we wrap up the episode, just want to give a shout out to Dave who just have submitted a talk to Py Italia I think it is.
[0:18:53.5] DA: Yeah, PyCon Italia.
[0:18:54.9] MN: PyCon Italia and he’s going to be talking about this very topic right here, well not right here but in Italy. So shout out man, I mean we don’t have a sound board but fucking awesome. It’s fucking great.
[0:19:06.6] DA: Yeah, it’s going to be chose your own adventure with GraphQL for client web services.
[0:19:11.2] MN: There you go, when is that?
[0:19:12.9] DA: It’s going to be in April, mid-April-ish.
[0:19:15.0] MN: Ah you’ve got a lot of rehearsing to do. Do you know how to speak Italian?
[0:19:18.9] DA: Alora.
[0:19:22.1] MN: Yeah, I know the GraphQL. I can’t Italian it for being so.
[0:19:28.5] DA: It just sounds like Bronx.
[0:19:31.0] WJ: Mon-giare.
[0:19:32.0] MN: Yeah, exactly. Look you could do it, you’re going to give a talk in Italian to William is that what it is?
[0:19:37.6] WJ: I think it is an English language conference right?
[0:19:39.3] DA: Yeah, there’s an Italian track but a lot of English speakers as well.
[0:19:45.3] MN: Oh that’s dope. I’m really happy that you’ve submitted the talk and that it’s been accepted and you’re out there and you’re going and I am really looking forward to seeing that YouTube video because I unfortunately won’t be able to go.
[0:19:54.4] DA: Yeah man, YOLO.
[0:19:56.3] MN: Yeah, exactly.
[0:19:57.2] WJ: Buy your chicken snack guys, it’s going to be lit.
[0:19:59.6] MN: Yeah, it’s going to be awesome.
[0:20:00.5] DA: Yeah, hopefully I can bring my field recorder in like try to interview some people while I’m out there.
[0:20:05.7] MN: Oh that would be cool. Yeah I mean I imagine we can fit that into the podcast and get some small content out of that.
[0:20:11.7] DA: Yeah, definitely.
[0:20:12.7] MN: Do we have any teach and learns? I learned a whole lot just now with GraphQL so Dave thank you. Thank you for that. Do we have any other teach and learn?
[0:20:20.4] WJ: Yeah actually I got one. I learned something from Dave earlier today.
[0:20:23.4] MN: Oh snap so.
[0:20:24.9] DA: Teaching, I teach people.
[0:20:26.9] MN: They pay you to teach people. There you go.
[0:20:28.9] WJ: There is this great tool out for React called Storybook and what it allows you to do is display all of your web components really easily in the browser so that the people can go and look at them and it provides different stories so you can configure the component to look different ways. So like if you have a button and you want to show that button like, “Here’s the story of the button when it’s disabled and then here’s the story of the button when it has an action associated with it.” Or whatever then people can go to this page and click around and explore all the different ways that you can configure that component.
What’s nice about that is it gives you an isolated place to do your building so you’re not reliving the entire page when you want to go and construct a new modification to that component. Your service is great as documentation and there’s this really cool feature where you can tie in tests and so on the story page, you can see all your test at the bottom.
And whether or not they are passing and that even ties into your regular test suite. So like if you are using Jest, when you are going to run your Gest test it will pick up the stories that you have already tested that you have written in the storybook.
[0:21:39.0] DA: Yeah, mad props for Santiago for helping us set that up like he was driving the Bit with that, setting up just in Storybook and I think that is going to be a big one.
[0:21:48.6] WJ: And if you want to work with Santiago who by the way is an amazing dude, his company is actually hiring in Madrid right now. So check out jooraccess.com and go to their career’s page.
[0:21:59.8] MN: Oh dope.
[0:22:00.9] DA: Yeah, props.
[0:22:01.7] MN: Shout out to Santiago. Cool that wraps up this episode, shout out to the co-host, the man himself, thank you for coming on down. GraphQL, we learned a thing or two.
[0:22:14.3] DA: Yeah thanks man.
[0:22:16.0] MN: And our producer, constantly producing and making sure this space is amazing to learn about GraphQL, like today.
[0:22:23.2] WJ: Happy to be here, thanks for having me.
[0:22:25.1] MN: I’m Michael Nunez. Feel free to hit us up at Twitter.com/radiofreerabbit and if you haven’t, please give us a five star rating on iTunes and subscribe. This is The Rabbit Hole, we’ll see you next time.
Links and Resources:
