Is it possible to use GraphQL with Core Data?

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

If you have an existing iOS app with a Core Data stack, is it possible to wrap that in GraphQL?

Ellen Shapiro: I wouldn't necessarily recommend it. It's definitely something you can do, but there's a certain point at which you're giving up some flexibility by doing that, because it means that if you have fields that are required, if you have properties that are required, you have to ask for them every single time, and that defeats the point of not over fetching. And so that's something where, either you have to make everything optional, which leads to other weird circumstances, or you have to look at a different way of thinking about some of this stuff.

Paul Hudson: So let's assume someone already has a working app that is not using GraphQL right now, it's using regular REST calls. Brad asks, “can you speak to how big of a lift it is to get server from REST to GraphQL? To move from what you have right now to a full GraphQL stack?"

Ellen Shapiro: You know, I think that's a really interesting question. I think one of the big questions is, how well is REST working for you right now? Are you working on a project where your APIs haven't changed in five years and aren't going to? At that point, you might as well just keep using REST. One of the big advantages of GraphQL is its flexibility, but if you have data that you don't need to be flexible then REST is going to be much easier to use.

We have a spec for multi-part form uploads in GraphQL, but it's something that is a little bit cumbersome to use. And it's a little bit weird to generate code for. And honestly, 9 times out of 10, the easier way to do it is to use just a REST post to upload stuff to an S3 bucket, get back the URL of whatever you uploaded it to, and then just send that as a string to GraphQL.

Because sending it as a string to GraphQL is much more what GraphQL is actually meant to handle. And the upload stuff is a little bit, I don't want to say stapled on, but it's not the primary goal of what GraphQL is doing. And so it's something where we want to be able to provide support for it, but we also want to say, “realistically, this is really something that we encourage people to seek out what is the appropriate way of doing each individual thing.” Because I think it is something where nothing is a panacea – nothing. Nobody in any amount of technology will ever say, “my thing solves every problem.” I will say that I think GraphQL solves a lot of problems, but it can cause other problems.

Whenever you're looking at a new technology you have to be realistic about what the trade offs you're making are. And I think, for me, there's a couple of places where GraphQL is really, really nice. One is if you have a really giant company where getting anything changed is a hideous pain, and you just need to be able to say, what is the underlying data here? And then I can do what I need to with that data. That's really helpful to be able to have a graph that you can query rather than having to query seven different end points to get the information for one screen.

The other place is really nice is in a fast-moving startup where you have stuff that's changing all the time. Maybe you've decided to pivot from travel to recruiting, and right now that seems like a pretty smart pivot. But it's definitely one of those things where, if you have a decent amount of stuff that's growing and not necessarily stable and you don't necessarily want to lock yourself into one structure, GraphQL is a really good choice.

If you have something that is locked into a long-term structure and basically isn't going to change, that might not be as good a choice for GraphQL. The other thing is that you can also mix and match. We definitely have people working with Apollo, who have some portion of their API that's essentially old and ossified and they're like, “don't touch anything, or it's going to collapse completely.”

“I think it is something where another place where REST can be really helpful is if you have a really performance-critical call where you're just making this call over and over again, and if you're not careful, it could potentially have an enormous impact on your database.”

They don't want to start looking at moving that stuff to GraphQL, because frankly it's going to be a mess. So, there's stuff where you can sort of say, “okay, for these pieces that aren't going to change, we can still use REST. But for these pieces that are new and are evolving, we can use GraphQL for those pieces.” And I think it's important to remember that it's not a completely A/B choice, and I think a lot of people feel like it has to be. There's definitely a lot of advantages from going like, "a large amount of our stuff is in GraphQL." But I think one way a lot of people get started with GraphQL is having one service where they've had these kinds of problems migrate to GraphQL rather than sort of having everything go to GraphQL at once and seeing, “okay, are we actually seeing these advantages that are being touted? Are they worse? The changes that we're doing?”

And you know, I think it is something where another place where REST can be really helpful is if you have a really performance-critical call where you're just making this call over and over again, and if you're not careful, it could potentially have an enormous impact on your database. That's something where if it's absolutely performance critical, where every millisecond counts, the more work that you can do on the server, then the less work that you have to do on the device. Then that's a place where sometimes REST calls make more sense.

It's definitely something where you're looking at the trade offs. What are you able to get out of GraphQL versus what are you able to get out of REST? And I think for a lot of people, it's always worth looking at those seriously, because there is a point where the new hotness is not necessarily what you actually need. But personally, what I see is that there are really big advantages to GraphQL at the very big companies scale especially, and the very small company scale especially. I think there are places in the middle where people can use it for particular services in a way that could be really helpful.

Paul Hudson: One last GraphQL question before we move on: can someone write a GraphQL backend in Swift, or would you recommend some other language for this purpose?

Ellen Shapiro: I know that a lot of the stuff that we use for examples is in Node. If you go to the Apollo website, there's a full-stack tutorial that's using Node.js. I know that there's a plugin for Vapor that someone's working on for GraphQL. And I'm mad that somebody beat me to it, but I'm glad that they're doing it and not me. It's definitely something where there's work going on around GraphQL. I know that there's definitely some stuff in Ruby. There's a bunch of stuff in Kotlin, which will also work with the Java universe.

I think there's a lot of options, if you're looking at back ends that are compatible with GraphQL. I think the front end choices are somewhat more limited, and that's where Apollo has become a little bit of a hegemony on some of it. But there's definitely other options, and I think there are instances where the way that our stuff is architected is somewhat opinionated. If you don't share that opinion, that's fine, that's totally fine. I think my position is that the more that GraphQL can grow in general, the better that is for Apollo and every company working on GraphQL. I think getting people interested in what are the basics of it and what are the benefits of it is really important today.

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