On today’s episode of the Rabbit Hole, we are talking GraphQL and getting some hot takes from our guest Stephen Meriwether! Although GraphQL definitely has its proponents, it certainly has its critics and there are a number of reasons for this. That’s what this episode is all about and with the help of Stephen we discuss some of the most important of these. We open with a short look at what GraphQL is used for and why it can be a good tool before we get going on some of the hot takes on its shortcomings. We talk the time it takes to learn and have command over it, its similarity to n+1, caching issues, data retrieval and more. So for a lot of hot takes, some good points on how GraphQL could improve and an all round interesting chat, be sure to tune in!
Key Points From This Episode:
Transcript for Episode 75. GraphQL Hot Takes with Stephen Meriwether
[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:11.9] MN: Today, we’ve got GraphQL hot takes. Dave, how do you feel about people bad mouthing GraphQL? I know you’re like an enthusiast, you love GraphQL, what do you think about this hot takes?
[0:00:23.6] DA: I respect every their opinions.
[0:00:27.0] MN: You respect the opinions of people who have hot takes towards GraphQL?
[0:00:30.9] DA: Yeah.
[0:00:32.0] MN: Awesome. Speaking of the hot takes that we have, we have a guest today, Stephen Meriwether. How’s it going, Stephen?
[0:00:37.4] SM: Great.
[0:00:37.6] MN: Could you tell us a little bit about yourself and your experience with GraphQL briefly before we get into these hot takes real quick?
[0:00:44.4] SM: Sure, I’m a consultant at Stride, in previous roles, I’ve maintained and actively developed on both GraphQL servers and GraphQL clients.
[0:00:54.2] DA: Before we get into the hot takes, first, why don’t we explain a little bit about what GraphQL is, in case you haven’t listened to the episode 52, it’s 2018 the year that GraphQL kills the REST, there’s another boldly titled episode.
[0:01:09.0] MN: Let’s jump right into what GraphQL is and it’s supposed to kill, REST altogether.
[0:01:14.3] DA: Do you want to get into like what it’s good for? What is the idea of it?
[0:01:18.1] SM: Sure, GraphQL is just a different paradigm of building APIs, we’re all really familiar with building RESTful APIs.
[0:01:25.8] WJ: Except for those Soap fans out there, sorry guys.
[0:01:29.4] MN: All the Soap fans, yeah.
[0:01:30.9] SM: The problem with RESTful APIs is you have many different clients, typically, you have mobile clients, you have web clients, maybe you have like a two sided e-commerce platform or they have clients, two separate sides of web clients and they all need different data from your server, right?
With the RESTful API, you would need to provide different end points for every data for your mobile client, for your desktop client, for your web client. The promise of GraphQL is that you build one end point and then the client can request the data that it needs. You don’t’ have to build multiple end points, you build one end point, the client request exactly what it needs and it’s a lot less overhead on a server.
[0:02:15.6] DA: Yeah, a lot more simple for the client too because you ideally would get everything that you wanted in one payload and then it would be in the perfect shape and you would have a wonderful time and that would be the end of it.
[0:02:29.6] SM: Exactly, not only is it a perfect shape, not only would you have a wonderful time but your only requesting the data you need and so, in a world where bandwidth is really important and really valuable, you don’t want to be requesting more data than your client actually needs.
[0:02:44.0] DA: Yeah, especially on mobile.
[0:02:45.7] SM: Yeah.
[0:02:47.4] DA: Low power devices, things like that.
[0:02:51.0] MN: One of the benefits being that requesting the thing that you want ultimately will resolve in less information than getting everything, even though you don’t want to and in REST, you would have to create a brand new end point to cover that and that would be very expensive for developers to think of every particular opportunity to make the callbacks or the responses to be small but GraphQL allows you to you know, make it in one end point and get exactly what you want.
[0:03:20.4] DA: Yeah, exactly. There’s like different ideas of architecture for API where you might have one API for everything and just have your different clients deal with the differences and just accept they’re not going to get the perfect data for what they need or you could have some internal services that different, like one end point per service that’s exposed, that’s more tailored to what they want and they would talk to the internal systems.
[0:03:47.9] SM: Another wonderful benefit of GraphQL apart from sort of having one end point is that your end point is now typed, right? You never run into the situation where you get a number that’s actually a string or you get an integer that is actually a decimal. That’s actually a string.
[0:04:03.4] MN: God.
[0:04:04.2] SM: Right? We’ve logged out with this and JSON RESTful APIs, when you have a typed API, you can be confident that the type of data that you're getting back is what the schema says it’s going to be.
[0:04:18.3] DA: Yeah. Having types allows for some nice development tools like you can have introspection and get nice linting and documentation for free like Graphical, all example of a really nice tool where you can just like interactively type and autocomplete your queries and you know, iterate very quickly and arrive at you know, what the exact shape the data is that you need and –
[0:04:46.5] SM: Yeah, the best example I’ve seen of that is GitHub’s new API. GitHub rolled out V4 of their API that was built in GraphQL, they have this API Explorer tool that they built, that lets you interact with other API via their web explorer page. Using Graphical, you can do all sorts of neat things and it’s really cool.
[0:05:06.5] DA: Yeah, it is pretty magical how easily it works, very complicated. I haven’t tried anything with it but it could be interesting messing around with.
[0:05:18.1] SM: Then the last big benefit I think of using GraphQL is you actually know what end points are being consumed. Since both the client and the server have to agree on what end points they’re going to consume, you can use stack analysis to see which of your end point’s exposed by your server act, should be in use. Or which types of your end points –
[0:05:38.1] DA: Yeah, I see what you're trying to from, where you can have kind of a contract between the two, that’s like, very easily verifiable.
[0:05:45.4] SM: Exactly. Having that verifiable contract sort of lends itself to two things. One, if you can identify that code really easily. In RESTful APIs, you don’t really know who is consuming your API, you know that at some point, someone was. If you want to delete it, you have to go to some like, you have to like deprecate it somehow and then verify that no one’s using it, then you can delete it and even might still break code and might still break your service that way.
[0:06:12.3] DA: Yeah, especially with mobile, that’s a challenging point.
[0:06:16.3] SM: Definitely.
[0:06:17.4] DA: Once it’s out there, it’s out there for good.
[0:06:19.2] SM: Exactly. Lastly, by the nature of just business logics, some end points are going to be really expensive, they’re going to have to do really complex queries or they’re just going to be expensive operations.
You can make a business decision as to whether or not to optimize those certain end points, or those certain types by just examining who is actually consuming them, right?
[0:06:41.5] DA: If you care about them.
[0:06:42.7] SM: Right? If you have a hundred consumers, maybe you should put some effort into making that faster, if you have one consumer then it’s not really a big deal,
[0:06:51.4] DA: Yeah, that’s a fair point. I think the other area I’ve seen on success with GraphQL is like as an API gateway, if it’s not, like directly coupled to the services but if you’re like micro services and it’s like unifying them in a nice way for the client to simplify that process.
That seems like a lot of folks have had good success with like Yelp and a couple of others. Enough good things -
[0:07:17.4] MN: Yeah, we’re here for the hot takes though. The hot takes what people want to hear.
I’m pretty sure there’s going to be a lot of angry tweets out there because we are sponsoring GraphQL hot takes and Stephen’s full of them.
[0:07:33.5] SM: This podcast brought to you by Facebook.
[0:07:37.7] MN: Let’s start off with one of the hot takes, Stephen, as you mentioned before, you have had experience with GraphQL, which I imagine is the reason why you have these hot takes.
[0:07:48.2] SM: Yeah.
[0:07:48.4] MN: You want to kick us off?
[0:07:49.6] SM: GraphQL is great as we talked about but there’s a lot of challenges, certainly. I think the biggest challenge is that it’s just a new skill you have to learn and so when everyone’s trying to build a product and trying to meet business requirements, we also have to learn this new skill of building a GraphQL API.
In very situation I’ve been in so far that requires multiple iterations of API design to get to something that’s reasonable.
[0:08:17.4] DA: There’s a kind of a shortage of GraphQL sherpas out there.
[0:08:20.5] SM: Yeah, definitely.
[0:08:21.9] DA: To guide people along the way. You do have to have a lot of maturity and like just take the fact that you're going to fail and then iterate –
[0:08:33.9] SM: It’s going to be really frustrating why you’re failing and it’s going to require multiple iterations.
[0:08:37.8] DA: I think even giving actually like they use GraphQL internally before they opened their beautiful V4 API into the world like I’m sure that while they were doing that, they were having a lot of experience about like what they liked and what they didn’t like.
[0:08:54.7] SM: Yeah, that’s a big thing is you know, a company the size of GitHub they have the resources to develop best practices internally. Most companies don’t have those resources and so since I feel like there’s not a lot of set in stone, sort of best practices decided by the community on API design, companies and teams have to sort of figure that out themselves.
[0:09:15.3] MN: Does that not normally happen when new technology emerges? I imagine React first came out, an example I can think of is the way you structure your React application in the various clients that I’ve seen, I’ve seen all sorts of different ways that the structure of your react project looks like.
[0:09:33.0] DA: Yeah. Beautiful snowflakes.
[0:09:35.1] MN: Yeah, they all work for the purpose at the time when they built it but isn’t that kind of what happens with GraphQL?
[0:09:42.4] SM: Definitely. I’m not saying it’s not an overcome-able challenge but that’s the primary reason why GraphQL isn’t goin to kill to REST in 2018.
[0:09:55.1] DA: Direct shot.
[0:09:56.0] MN: There you go.
[0:09:57.7] SM: Yeah, but the community we eventually settle on something and building API’s and GraphQL, we come a lot easier, we’re just not there yet.
[0:10:05.2] DA: Yeah, I think that one of the interesting things about using GraphQL is that it kind of has this framework and it forces you to consider the API design a lot more closely. If you don’t do that then you can paint yourself into a corner and then have to like, you know, refactor entire things down and – you can get away with a lot less than you can with rust and I respect from the design angle.
[0:10:28.8] SM: Exactly, you don’t really realize that you dug yourself into a hole and so you’re already in the hole and then you have to sort of walk yourself out somehow.
[0:10:37.0] DA: Yeah, especially if you got some performance issues. Hot take about performance?
[0:10:44.8] SM: Yes, personal opinion but GraphQL is n+1 as a service.
[0:10:52.8] MN: The hot takes are real.
[0:10:54.0] DA: It burns.
[0:10:55.8] MN: Elaborate on that.
[0:10:57.4] SM: Okay, n+1 is when you have relational data and you have to query end times for your relationship and t hen one time for your primary model, right? We're all very familiar with building SQL queries to avoid n+1 and so if you have a RESTful endpoint that just, I want all my post and post have commenters and commenters have other comments and what not, we can design sequel queries to efficiently do that with GraphQL, you don’t know if the person who’s request of your client that’s requesting your post is also going to request for the post commenters or the post author.
You just don’t know that at the time you’re writing the code. Its’ really hard, yeah, this is really hard to sign the API in a way that you can provide the post comments and the post author without running into N plus one problems.
[0:11:51.6] DA: Yeah, if you try to pre-optimize and like pre fetch data, then, if they don’t fetch that data then –
[0:11:59.2] SM: It’s work that’s –
[0:12:00.9] DA: Just waste it, you’re not living the dream of like having the most efficient, minimal effort.
[0:12:09.9] SM: This isn’t – again, it’s not an unsolvable problem, people realize that this is a thing, GraphQL being an n+1 as a service isn’t an original idea but – there are tools being built like GraphQL batching to sort of help mitigate this issue.
[0:12:25.7] DA: Yeah, I think that’s popular for Ruby I think?
[0:12:29.7] SM: Developed by Spotify.
[0:12:30.8] DA: There’s a similar tool for the Python library Graphene modeled off to Facebook data loader. Similarly like where they will batch the requests, you might have like kind of this fan out which maybe is addition of the n+1 thing where you might have like one order that has 10 items and then the 10 items have five different sizes and so you have each of those things getting request in naively. You have multiplicative levels of queries but if you do batching, do a lower, then you can get each level collected and get it in batch.
[0:13:14.3] SM: Right, yeah. The community’s definitely coming up with solutions to these problems but right now, it’s sort of a lot of work to implement these things and by default, most GraphQL APIs are just going to have lots of n+1 queries, that’s just something we have to be okay with.
[0:13:31.8] DA: Yeah. Build more better open source projects or something. I have a hunch in too.
[0:13:43.2] MN: What?
[0:13:45.1] DA: Caching in the client if you’re using a library like Apollo or Relay is pretty great but it can shoot you in the foot.
[0:13:55.8] SM: Explain.
[0:13:58.1] DA: If you have data that you fetch down, and then you’re doing things to it, maybe making changes, the data in the cache maybe come invalid and you have to either design your mutation which is the operation that you do to change data in GraphQL. Such that you can fetch exactly all the data that you’ve pulled in every other place and then put it back in your store.
Or, you need to just call bankruptcy and blow up the entire cache or in the worst case, there’s actually a bug out there, I think that Apollo is working on if you do not fetch every single field on a record that you’ve nearly created then it will just silently fail.
[0:14:42.2] MN: Wow.
[0:14:42.5] DA: They will just blow up and that is like the most painful respective.
[0:14:47.2] SM: That sounds very painful.
[0:14:48.9] WJ: Gosh.
[0:14:50.2] SM: But I can relate to the caching with mutations and specifically, every mutation I’ve ever written, I’ve had to go back and change the return type because I didn’t return the right data and it wasn’t updating the Apollo cache correctly. That’s just really frustrating.
[0:15:03.4] DA: Yeah. That’s my biggest argument for doing full stack slices when designing mutations because I think the hardest thing is deciding what you need to return and that’s like really driven by what the needs of the client are.
[0:15:17.0] SM: Exactly. Mike, I have a question for you.
[0:15:19.7] MN: What up?
[0:15:20.7] SM: You’re a smart guy.
[0:15:21.3] MN: I try, I mean, I don’t know about all that but yeah, sure.
[0:15:24.6] SM: When you need data from your server, what HTTP verb do you typically for?
[0:15:30.6] MN: When I need data –
[0:15:31.6] SM: When you need to just get a whole bunch of data.
[0:15:34.3] MN: Is it a GET?
[0:15:35.1] SM: It is a GET.
[0:15:36.7] MN: There you go, because I want to get data, that is correct, check mark for me.
[0:15:41.7] SM: But Dave, if I need to do the same thing with a GraphQL API, what HTTP verb do I have to use?
[0:15:49.7] DA: This is a trap. Use a GET with a query in the query string no you don’t that’s a horrible idea.
[0:15:58.1] MN: Don’t do it.
[0:15:58.5] SM: No, you use a post. I don’t understand it. It’s so frustrating, I’m looking at my network tab, its’ a whole bunch of posts and it just says, query, it’s a post with queries and the network tab tells me nothing. I have to click into each individual row to figure out what query I was doing, if it was a mutation.
[0:16:20.1] DA: Yeah.
[0:16:20.4] SM: Do you have experience with frustration?
[0:16:21.8] DA: Yeah, I mean, I like the fact that all of the end points are the same, filter by GraphQL but then you don’t know what queries are firing when, yeah.
[0:16:33.2] SM: If a query fails and this is just a red line and a network tab, I don’t know what query is that, I have to do an extra click to click into it.
[0:16:39.9] DA: My god.
[0:16:41.0] MN: Are you Vim user? Is that what you’re telling us? You don’t want to click nothing, of course.
[0:16:46.3] DA: Yeah. Yeah, that is a little challenging. I know that Apollo has some pretty good dev tools that will help you monitor queries that are actually being fired and fetched but I think you still need to click. They’re not going to save you there.
[0:17:04.1] MN: Vim community, you got to come up with something to help, to help Steven out.
[0:17:07.1] SM: Apollo is great so definitely, I would recommend if you're using GraphQL on the front end, I have experienced with Apollo and it’s phenomenal.
[0:17:15.8] DA: Yeah, this is probably my complaining about caching, I enjoy it muchly. Kind of related to the post request thing that you’re talking about. You can’t really do traditional server side caching like you do with Rust.
There’s another area where you know, people need to work as a community and figure out what to do because if everything is just post to GraphQL, how do you cache it, you can’t use that but thin HTTP caching that you kind of get.
[0:17:45.8] SM: Yeah, you completely lose in that work later caching.
[0:17:48.3] DA: Yeah.
[0:17:48.7] SM: Which can be a problem.
[0:17:50.0] MN: Post all the things.
[0:17:51.2] DA: Post all the things. There’s some solutions that Apollo is working on like as a service, you know? Again, it’s like, a little baby solution, still working on it.
[0:18:00.6] SM: Yeah, it’s still relatively new and again, I’ll reiterate this, I don’t think any of these problems are unsolvable which is not there yet.
[0:18:08.2] WJ: Why post? Why did they do that?
[0:18:10.7] SM: That’s a great question.
[0:18:11.5] DA: I’m assuming because a query string is pretty long, if you send that over the wire and the URL, that’s – you can hit a wall with that.
[0:18:20.6] SM: Yeah, because I guess that makes sense, right? Because you have to build out this big query that you have the data that you want back and so it could be pretty long, yeah.
[0:18:31.3] DA: Also, it’s not REST, it really isn’t REST.
[0:18:34.8] MN: Paradigm.
[0:18:35.9] DA: Although offends the REST sensibilities, you know, just looks gross, it’s just not REST anymore, it’s a completely different thing. It doesn’t obey the rules, although I did see someone asking question the other day about like adding data to the body of a GET request which is – that’s a special breed of REST as well.
[0:19:01.4] SM: I am pro body with GET request, I don’t see a problem with that.
[0:19:06.6] DA: Yeah.
[0:19:08.5] WJ: When you sign up for GraphQL, you also signup to never see your Facebook ever, right? This is the price that you pay? You sign away your soul, to your Facebook?
[0:19:17.7] MN: I thought that would happen when you use a Facebook account too, I don’t know.
[0:19:21.1] SM: Facebook owns the application if it’s GraphQL.
[0:19:25.3] MN: I mean, they own you too, yes.
[0:19:27.8] DA: Very extensive terms.
[0:19:31.9] SM: Yeah, I think you're referring to there’s a big issue with the React and GraphQL community about a year ago where people started noticing that all of Facebook’s open source tooling was using this BSD plus license which was very much like a BSD license except it had this extra clause that says you can’t sue Facebook for anything.
Since I think late last year, they changed all of their open sourced tooling and libraries to use MIT, I think now we’re all safe.
[0:20:02.9] MN: Now we can sue Facebook?
[0:20:04.5] SM: Yes, you can.
[0:20:06.1] DA: All right, let’s do it guys.
[0:20:08.5] MN: Let’s all beg together.
[0:20:09.6] WJ: n+1 lawsuits.
[0:20:18.9] MN: Stephen, you’re telling us that we should go back to that episode of The Rabbit Hole and change it, well, GraphQL be it in 2020? Not 2018?
[0:20:30.3] SM: 2020 sounds right, yeah.
[0:20:32.0] MN: But two years from now, that’s when GraphQL will be ironed out.
[0:20:36.3] SM: Everyone should go home and still build RESTful, APIs is what I’m saying.
[0:20:41.0] MN: Hot takes, don’t –
[0:20:42.2] DA: No, disagree, all right, part two coming soon.
[0:20:47.4] MN: Man, don’t go –
[0:20:48.7] WJ: Dave, do you have a rebuttle?
[0:20:50.1] DA: Wait, just the –
[0:20:51.0] WJ: Go home and write REST APIs.
[0:20:53.2] DA: You can go home and write REST APIs?
[0:20:54.5] MN: Don’t let him tell you how to live your life. Don’t let him tell you how to live your life bro, you want to write it in GraphQL, you do that.
[0:21:02.6] DA: Yeah, I really have enjoyed the art of the n+1 query, I had gotten very good at it, I don’t know. I think it’s a fun area and like you're saying, there’s a lot of things that are not perfect yet but I think that’s one of the things that makes it really exciting for me because I can go and write a REST end point but I can google like everything about REST end points and there’s no problems that are like really interesting to solve, technology wise. Except for the business case that you’re trying to write for.
[0:21:33.2] WJ: Right, if you need more problems, use GraphQL.
[0:21:37.1] SM: I’ll rephrase. Go home and write a GraphQL API for fun but build your business on RESTful APIs.
[0:21:44.1] MN: Until it’s safe to do so or never use GraphQL.
[0:21:47.3] SM: Until the rabbit hole has a podcast in 2020 that tells you it’s safe to now do that.
[0:21:53.1] MN: This guy, perfect.
[0:21:54.1] WJ: Love it.
[0:21:54.9] DA: Part two coming in three months.
[0:21:59.6] MN: Awesome. Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into the rabbit hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources: