The killer features of GraphQL: code generation, flexibility, and efficiency

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

Can you give some practical examples of where GraphQL really works well for Swift developers?

Ellen Shapiro: I think the example that I was just talking about in terms of having a designer who wants to do changes or having some kind of change that needs to happen to the UI while the underlying data structure doesn't change at all, that's, that's something that GraphQL really excels at, is being able to say, “hey, we've made new stuff available really, really easily,” and be able to say, “okay, all you have to do is just add this particular thing to your query or your mutation.”

Mutations are basically a type of query where you can tell the backend to make changes. So you can basically say, “okay, now I want to start using this thing,” and you can start using it basically immediately.

“And if you are able to say, ‘Okay, I know that I'm asking for these things and I know that you're going to give me these things back,’ that means we can generate code that will do all of the parsing for you.”

Paul Hudson: Okay. So we've got flexibility, stacks of that, because you can request more changes, it's very clear what's actually there and what you are going to want to request and so forth. Plus efficiency, you get only the bits you actually care about. And those two seem to be the real two killer features of GraphQL. Are there any more you're thinking about?

Ellen Shapiro: I think the big one on iOS and the one that I spend most of my day working on right now is code generation. So because you have the schema that defines everything that you can ask for and the type it will be, and then you have this query where you can validate it against the schema and say, “hey schema, I want to ask for all of these things, is that possible?” And if you are able to say, “okay, I know that I'm asking for these things and I know that you're going to give me these things back,” that means we can generate code that will do all of the parsing for you, do all, do a bunch of stuff in terms of caching, basically give you a large chunk of a network layer without you really having to do anything.

That's where I have a job. So right now, when Apollo for iOS was originally released, it was made by a guy named Martijn Walraven, and Martijn is an absolutely amazing programmer and was really super enthusiastic about Swift, but he also got pulled off onto other projects. And unfortunately some of the design choices that he went with made it a little bit harder for people who were more traditional iOS developers to work with it, because he made some choices that were based on the fact that he's a much stronger JavaScript developer than he is a Swift developer. So there's a bunch of stuff that happened there. There's also a lot of bit rot because there was a long period of time where there really wasn't anybody maintaining it. So my job has been to come in, really try to update everything, try to fix as many of the small bugs as I can. And I got through that part, now I'm at the point where I'm like, okay, I have identified where all the structural problems are and here's my sledgehammer.

Paul Hudson: But that part is the bit you do for Apollo, but the other two flexibility and efficiency, that's a general GraphQL benefit, everyone gets from GraphQL.

Ellen Shapiro: Yeah, that's definitely true. This is why GraphQL is getting popular – people are seeing these advantages. I think Apollo in particular is popular because we provide this Code Generation that allows you to essentially skip 47 steps of getting all of this set up. And it's definitely not as straightforward as I'd like it to be, but it's a lot easier than writing it yourself.

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