Why should iOS developers use GraphQL?

Recorded March 26th 2020 – watch the full episode on YouTube.

For folks who are just trying to figure out what GraphQL is and how it could work with their iOS app, could you give us a summary of what GraphQL is and why it’s so useful?

Ellen Shapiro: It's definitely one of those things where it's like, “ooh, it's a buzzword.” So Apollo is a company that actually used to be called Meteor JS, and they actually had a big JavaScript framework. And when Facebook open-sourced GraphQL, they had been looking for something to help manage interacting with your data better. And they said, “okay, this really looks like an excellent candidate." And they started working on an open-source implementation of it immediately and have basically become the leaders in this for both server and client in particular.

And there's huge, huge depths of knowledge about this on web, where some of the problems are a little bit different than they are on mobile. I think on mobile, for me, the biggest thing that drew me to GraphQL was the idea that anytime I make a REST request, I get back a prespecified amount of data that says, “okay, I asked for a user." So now I get back the user's username, date of birth, their address, their billing address, their shipping addresses, and for whatever I'm displaying, how much of that do I actually need at any one time?

And the idea with GraphQL is that there's a thing called a schema that is produced by whoever's managing the graph, which is usually some combination of everyone, but is usually manually managed by the server-side team.

And the schema is basically a thing that says, “here are all of the things that you can possibly ask for or make changes on." And you can look at that schema and then you can create these things called queries, and you can say, “okay, you said that here's a user and here all of the possible properties that I could ask for on user, give me these two.” And then you will only get those two properties back for a user. And that's something where, both from a standpoint of efficiency in terms of not over-fetching data, and from a standpoint of flexibility, I really felt like this was something that would work really nicely with mobile. And I think my recollection is that Facebook originally started working with GraphQL to solve some of these problems on mobile.

“I find the biggest advantage to be flexibility at development time, because I think a lot of developers have run into the problem where they have the REST end point that they're hitting for a particular screen.”

Paul Hudson: Presumably, when we know we have a shaky connection, 3G back then but also even 4G today in most parts of the world, you don't want to have lots of data coming through because it's just wasteful.

Ellen Shapiro: Yeah. And it's definitely something where people are on unlimited data plans. You don't really want to push people's data plans, particularly in developing countries. I was in Laos in January and I had like Edge the entire time was there.

It wasn't as bad as I thought it was going to be, but it's definitely something where if you only need to display a couple of pieces of information, getting way more information than that is just going to make your calls unbelievably slow. And so it makes it much, much better to say, “okay, only give me back the pieces that I need."

Personally, I find the biggest advantage to be flexibility at development time, because I think a lot of developers have run into the problem where they have the REST end point that they're hitting for a particular screen. And a designer is like, “hey, why don't we display this additional piece of information on that screen?" And you go, “well, that piece of information is not actually part of the rest end point that we have.”

I would need to go to the backend team, ask them to add that to the rest end point that we already have. They have to go through an entire bunch of changes in order to make that happen. And then basically that winds up taking about a month because they're like, “okay, well we need to do one sprint to build it, and then one sprint to test it, and then we'll deploy it.” And then you can actually start programming this design change that your designer wanted. And meanwhile, they're onto something four miles down the road.

I think the nice thing about GraphQL is, it gives everybody a list of what is possible. And if it's in the list of what's possible then it's possible, and if it's not in the list of what's possible, then it's either not, or you should talk about adding it.

It's something where it makes that change much faster. So you just change the query to get back that additional field, and then you can iterate on that design so much faster. I think it's something where, there's some stuff that does become more tightly coupled, but I think one thing that decouples, that I found to be really, really useful is communication between backend and mobile, in a way where you can get the data in the shape that you want it to be in. And it just makes your life a lot easier when you need to make changes.

Paul Hudson: Okay. We've got a question here from Renato Silva, because a lot of folks have used or heard of GraphQL, but haven't used GraphQL: “is GraphQL only the query language, or does it refer to an actual database?"

Ellen Shapiro: So the query language is GraphQL. You can actually hook GraphQL up to any type of database. Apollo Server is designed to be able to talk to any number of different kinds of databases.

And that's part of why they actually started doing in the first place is because I think they were really heavily tied to one particular type of database. And they were like, “well, that's silly.” And so they were like, “let's use the thing that, can talk to any database.”

Sponsor Hacking with Swift and reach the world's largest Swift community!