Uploaded March 2025 | Updated September 2026, 6 hours ago
Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of Developer Relations at Square, and today I'm joined with Alex Hancock and Watson from Apollo. Feel free to just go ahead and give us a quick little intro. Tell us about yourselves, what is it that you work on? And let's start with Alex.
Alex Hancock: Sure. Thanks for having me. I'm really excited to join this chat and talk with you guys today about all things GraphQL. I'm a Software Engineer here at Block. I've worked at Block for eight and a half years, and I most recently spent four years working on the GraphQL platform at Block.
Michael Watson: So my name's Michael Watson, I'm head of Dev Rel at Apollo. I've been there for about seven years now, and I really just work on GraphQL projects and kind of everything GraphQL. So I'm really excited here to talk more about GraphQL because I have a big passion and I'm obsessed with GraphQL, so this is fun.
Richard Moot: Awesome. I'm so glad to have you both here because we started on GraphQL here at, well, it was called Square at the time, but at Block for quite a while. It's been over five years I think. I mean, I feel like Alex could maybe keep me a little bit honest here. I just remember sitting in a round table with folks from Apollo and Strava and a bunch of others where we're just trying to figure out how should we build this and move forward. And so yeah, it's used pretty extensively here in some ways that we can talk about some ways that we can't talk about. But yeah, I think one thing I'd just like to kick things off with is talking about public GraphQL APIs and growing the adoption of those. I think that both of you have interesting ways of assessing that and looking at that. So I mean, either one of you want to tell us a little bit about public GraphQL APIs.
Michael Watson: Yeah, GraphQL has been around for a long time and I think public GraphQL APIs is something that's been on the rise. There was a lot of early adopters, I think of Shopify, GitHub's V4 GraphQL API, and the thing that I really love about it, if you look at the world before GraphQL APIs in the public space, you had your REST APIs, let's say even Square’s documentation of their REST API. There's a lot of great information in there, but as a developer that's coming to maybe a developer portal starting up with that API, they really have to start understanding of what are the domain entities I need to get into? And then there's always the orchestration problem like, okay, I got this one thing, now I need to make a second API call to go get this other thing. And that's kind of some of the magic that GraphQL provides is as a developer, I'm no longer thinking of these different endpoints that I'm getting and how I'm orchestrating them together, although that provides a lot of flexibility, but really sometimes I just want to add a couple extra fields into the request I'm making and just get that information and I don't have to think about what are the details.
And the magic sauce that I've seen in public Graph APIs that's really successful is this magic button that you click into the docs and it just logs you into that thing and then you could just start exploring and running GraphQL operations and seeing that right away instead of downloading a Postman collection. So I'm a big fan of that experience for developers just to explore to get up and building faster.
Richard Moot: Yeah, I couldn't agree more. I mean, one of the things that I work a lot on our REST APIs and I've been doing that for quite a while. One thing that always feels like a huge unlock for GraphQL over REST, not like we have to pit them against each other, but REST is really great about understanding the semantics of what are resources, what a resource might be doing given certain things. But the biggest missing piece that GraphQL does really well on is giving you the relationship between these entities and these resources. And it's just completely evident as you start navigating it. Like, oh, an order works with a customer or works with a payment and works with items because I see this directly in here. Instead of having to go and like, okay, I see the resource, now I have to dig through all the docs to figure out what do I use this with? So yeah, it's very, very great to see in that way.
Alex Hancock: Yeah, I would add I agree with all of that. I would add I think the most useful parts of GraphQL to me when thinking about public APIs are some of the most basic features of GraphQL, like field selection, just basic solving the basic problems of either under or over fetching of data depending on the client's needs. I think in the era of public APIs before GraphQL, you saw a lot of times some of those janky kind of custom built or half-baked ideas of adding field lists or something like that to REST API. And I think that how prevalent those were in public APIs speaks to the need for customization at the public API...
Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of Developer Relations at Square, and today I'm joined with Alex Hancock and Watson from Apollo. Feel free to just go ahead and give us a quick little intro. Tell us about yourselves, what is it that you work on? And let's start with Alex.
Alex Hancock: Sure. Thanks for having me. I'm really excited to join this chat and talk with you guys today about all things GraphQL. I'm a Software Engineer here at Block. I've worked at Block for eight and a half years, and I most recently spent four years working on the GraphQL platform at Block.
Michael Watson: So my name's Michael Watson, I'm head of Dev Rel at Apollo. I've been there for about seven years now, and I really just work on GraphQL projects and kind of everything GraphQL. So I'm really excited here to talk more about GraphQL because I have a big passion and I'm obsessed with GraphQL, so this is fun.
Richard Moot: Awesome. I'm so glad to have you both here because we started on GraphQL here at, well, it was called Square at the time, but at Block for quite a while. It's been over five years I think. I mean, I feel like Alex could maybe keep me a little bit honest here. I just remember sitting in a round table with folks from Apollo and Strava and a bunch of others where we're just trying to figure out how should we build this and move forward. And so yeah, it's used pretty extensively here in some ways that we can talk about some ways that we can't talk about. But yeah, I think one thing I'd just like to kick things off with is talking about public GraphQL APIs and growing the adoption of those. I think that both of you have interesting ways of assessing that and looking at that. So I mean, either one of you want to tell us a little bit about public GraphQL APIs.
Michael Watson: Yeah, GraphQL has been around for a long time and I think public GraphQL APIs is something that's been on the rise. There was a lot of early adopters, I think of Shopify, GitHub's V4 GraphQL API, and the thing that I really love about it, if you look at the world before GraphQL APIs in the public space, you had your REST APIs, let's say even Square’s documentation of their REST API. There's a lot of great information in there, but as a developer that's coming to maybe a developer portal starting up with that API, they really have to start understanding of what are the domain entities I need to get into? And then there's always the orchestration problem like, okay, I got this one thing, now I need to make a second API call to go get this other thing. And that's kind of some of the magic that GraphQL provides is as a developer, I'm no longer thinking of these different endpoints that I'm getting and how I'm orchestrating them together, although that provides a lot of flexibility, but really sometimes I just want to add a couple extra fields into the request I'm making and just get that information and I don't have to think about what are the details.
And the magic sauce that I've seen in public Graph APIs that's really successful is this magic button that you click into the docs and it just logs you into that thing and then you could just start exploring and running GraphQL operations and seeing that right away instead of downloading a Postman collection. So I'm a big fan of that experience for developers just to explore to get up and building faster.
Richard Moot: Yeah, I couldn't agree more. I mean, one of the things that I work a lot on our REST APIs and I've been doing that for quite a while. One thing that always feels like a huge unlock for GraphQL over REST, not like we have to pit them against each other, but REST is really great about understanding the semantics of what are resources, what a resource might be doing given certain things. But the biggest missing piece that GraphQL does really well on is giving you the relationship between these entities and these resources. And it's just completely evident as you start navigating it. Like, oh, an order works with a customer or works with a payment and works with items because I see this directly in here. Instead of having to go and like, okay, I see the resource, now I have to dig through all the docs to figure out what do I use this with? So yeah, it's very, very great to see in that way.
Alex Hancock: Yeah, I would add I agree with all of that. I would add I think the most useful parts of GraphQL to me when thinking about public APIs are some of the most basic features of GraphQL, like field selection, just basic solving the basic problems of either under or over fetching of data depending on the client's needs. I think in the era of public APIs before GraphQL, you saw a lot of times some of those janky kind of custom built or half-baked ideas of adding field lists or something like that to REST API. And I think that how prevalent those were in public APIs speaks to the need for customization at the public API...
