| < The killer features of GraphQL: code generation, flexibility, and efficiency | Is it possible to use GraphQL with Core Data? > |
How to integrate GraphQL with your iOS app
Recorded – watch the full episode on YouTube.
Is there anything Apple developers can do that will make integrating GraphQL easier?
Ellen Shapiro: Honestly I think a lot of the stuff that would make integrating GraphQL easier is stuff that applies much more broadly to code generation. I think a lot of the stuff that makes this setup a lot more annoying is basically the absence of Xcode plugins. There's Xcode extensions, which have a very, very limited amount that they can do.
“It's very different from just being able to shove everything into a database, the way that you can from a REST end point where you know exactly what you're getting back.”
Back in the day, I wrote an extension for Xcode called Xcode auto basher, where you could basically say, “okay, watch this directory or watch this file. Any time it changes, run this script.” It was nice because I could use that to automatically regenerate all of my model objects when I had changed the Core Data model, or automatically regenerate this file that had type safe access as to everything in my asset catalog whenever I put something new in the asset catalog or took something out of the asset catalog.
And that's something where, the fact that it’s not super easy to do in iOS without having to do run script build phases and having to do some other weird nonsense, that's really a huge thing that is annoying. I think from a standpoint of general GraphQL, one thing to remember is that this is ultimately something where you are sending a bunch of JSON to the server and the server is sending you a bunch of JSON back. And there's potentially other implementations where you could use other formats. But for right now, the overwhelming majority of GraphQL implementations are using JSON. And I think it's something where if you can remember that, ultimately that's what you're doing. It's much more about trying to wrap your head around, what are the places that I need to ask for stuff? And then particularly once you get into using a library, how has the caching worked on this kind of thing?
It's very different from just being able to shove everything into a database, the way that you can from a REST end point where you know exactly what you're getting back. You can't say, “okay, I'm going to make a user object that has the following: it has a required ID, it's got a required username. It's got a required address.” Well, the ID can be required, but if you didn't ask for it, you're not going to get it. So you can just say, “hey, I want user, username." And that's the only thing it'll give you back.
And so you can't just shove that into a database that says, "your ID and your address are required," because then the database is like, "these required objects aren't here." So there's a lot of stuff around that's really confusing for people, and I completely understand why. There's a lot of stuff about how you have to work to cache that kind of thing that's extremely complicated, but it's definitely something where starting with understanding, "What's the idea here? What is the problem that we're trying to solve?" And then going from there, I think is a big thing.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SAVE 50% All our books and bundles are half price for Black Friday, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
