Understanding the current state and near future of GraphQL

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 layer that GraphQL just its core functionality handles really well. And the other thing I would say is that the bigger the gap between a group of people producing an API like the communication gap, how hard it is for you to communicate, right? Are you on the same team? Are you in the same organization or are you not in the same organization in completely different countries? Like the gap between a company's engineers and open source or third party API consumers, the farther you are towards the side where there's a big communication gap, the more GraphQL helps I think because it lets the consumers customize the data that they're fetching without the API producers needing to build a bespoke endpoint that is exactly what the consumer needs within an organization where you're very close, you can spend the time to do that, you can build a custom API for somebody that meets their exact need, that's going to be very performant and it's going to be very optimized. But with GraphQL, you can get something that works for a broad range of use cases and you don't need to communicate and collaborate as much between API producer and API consumer. So I think that helps a lot for public APIs

Micheal Watson: A hundred percent. I mean to really ground that, one of the things I think about, let's say you have a REST API that you're offering out as public, you have this developer portal. You're trying to make everything self-service, right? Developers just sign up, get an API key, start making API calls. But here's the thing, all of your APIs, you have some functionality that you provide. Think of your existing website, your existing apps. There's things you can do with your business, your product, and people are trying to add flavors of that using your REST API into their world. Now, the thing I love about GraphQL is it actually gives you a secret benefit as a business that I don't think gets called out enough. You have a lot of tools today like AI, copilot, where I give it an open API specification and it writes me some fetch logic.

But what that really is starting to point at is that custom code that all of those third party developers are starting to write. Now, how confident are you that all of those are being optimized? Those are all written the right way. How many times have you had a REST API where you had to cut off an API token because someone was hammering your REST API, when really they just didn't follow those docs pieces? I mean, I'm guilty of it when I use a new product, I don't go to Docs first. I just start using it, clicking around, hammering it with calls. But with GraphQL, when they write that operation, they add those fields of exactly what they need. The execution actually on your end as the API owner is standardized. It's known. It's structured, right? This is where the declarative aspects of a GraphQL schema really come to your benefit.

So you now have an understanding of like what's actually going under the hood. And I've actually known a lot of GraphQL APIs you mentioned it's not REST First GraphQL or one or the other, and there's a lot of GraphQL APIs that actually call directly just to the REST APIs under the hood. I've seen that very common, and there's nothing wrong with that actually. It's a very known way of this type of operation is going to make this many REST API calls, and it becomes a way of you controlling that orchestration and it's also a benefit to the other developer. They don't have to worry about that orchestration anymore. Right? It's kind of just handled for you with just riding a GraphQL operation.

Richard Moot: Yeah. In fact, my first talk I ever gave on GraphQL is literally just trying to take a REST endpoint and just wrap GraphQL around it and basically saying like, Hey, here's a way to interact with my REST endpoints. And it was just stitching the two together. And at the time, I didn't feel like I actually understood a whole lot about it, but it was very interesting to just see how much more useful it became, especially because that separation of concerns from the front end developer who's just going to consume this doesn't really have to think very deeply about how are they actually creating these queries. And so that separation makes it a lot easier for them. I've always had this notion, which I would love to be dispelled, is that for the front end of a graphical API, amazing developer experience, but that sometimes on the backend can be this crazy amount of optimization or way of trying to power these queries. And that's why we end up having things like evaluating query load or depths to make sure, hey, we're not going to overload some relational database queries.

Alex Hancock: There are some gotchas for sure. I mean, there are common things you have to handle when a resolver could be run on a bunch of objects in a list, there's a known solution for that with data loaders. There are things that come up of GraphQL, but I would also say that the complexity introduced by almost any backend solution that's going to provide an API right performance optimization. You see people do all kinds of crazy things with needing to cache certain results, different endpoints being hard. And I think one advantage GraphQL has in this area over other API technologies is that if you're fetching and returning a big object, if there's a field or a few fields in an object that are really expensive to compute and they don't get queried in a GraphQL operation, then never, that code never even runs, right? Whereas responding to an RPC endpoint with a fixed set of data, unless you're using field masks or something like that, it's always going to compute that data even if the client doesn't need it. So the GraphQL Hertz performance myth is kind of, it's like, yes, there are some challenges that get introduced, you have to solve them, but there are challenges with any other API technology as well.

Michael Watson: Yeah. I also think you put some of those challenges on the client developer without GraphQL, those challenges don't necessarily exist from the performance standpoint. You're just kind of like, ah, I don't see them just that client developer writing that app because everyone has this, right? You build this nice UI and then someone's like, Hey, I don't need that data to start interacting with the page. I want a faster time to first interaction. So how do we progressively load that? And then you start thinking of the component structure in your client app and what you're doing with suspense and starting to handle multiple of these calls. There's also some really great solutions in GraphQL. One of the things that's come out recently in the past couple of years is at Defer, which just lets a client developer put some metadata in their operation and then actually have that data chunked down. So now you could really have one query per page and then progressively load that information into those individual components or have a fragment for an individual piece that's like a micro frontend strategy, which is really popular now.

Richard Moot: In fact, I think you put it really well there that a lot of the times, even in REST that we push a lot of that complexity down to the client. In fact, I just recently have been working with teams on trying to implement what we all fully acknowledge is a GraphQL feature within our own REST endpoints of we want to have this thing we call an includes pattern where you could say like, oh, I want to fetch an order, but please, I'd like to include customer data. Can you enrich this to go fetch related customer data? And as we're codifying it, we're like, we know that this is GraphQL, we would say, you can just go use GraphQL for this. But in certain contexts they're like, well, I really don't want to switch everything over to REST or from REST to GraphQL, so I'd rather keep it in one. But that's why we limit the scope of it and say, yeah, you can fetch one thing, but if you need anything more complex than this, please go use the GraphQL endpoint.

So one thing I was wanting to talk about is in the growing of, it doesn't have to be public APIs, but in the growing of APIs, I know when we first started out on this, GraphQL was a little bit earlier, I think there was mature groups out there with it in GitHub who had public GraphQL endpoints and everyone was getting really excited about it. So GraphQL has not gone away. It's only grown more and more. I think one of the things I'm curious about to talk with both of you is how companies can actually grow their graphs. Because I think there's working with legacy software, legacy things, how do you sort of adopt different data into this? And I'm kind of leading into wanting to talk about federated GraphQL. It sounds like a really useful strategy for compositing in what you want.

Alex Hancock: Yeah, I think adopting federation is a big first step for a lot of people. I mean, especially if you're in an organization or working in a project that has a microservice architecture, it's a really nice thing to add in. And I think it's nicer the earlier you start with it in mind, if you design your servers, your microservices with GraphQL as an interface from the beginning or from as close to the beginning as possible, I think the nicer, the nicer and nicer that experience is for Tech Stacks and organizations that are microservice based but are older and have historically used some other API technology, it's a little harder. But I think the story is getting better and better there. And I think the way to grow graphs, the key driver to growing a graph in my view, is to make it as easy as possible for data producers to add their data to the graph. If that's too hard, if that takes too much work, then the data producers will ultimately just do something else. They'll do what they need to get the data into the client app, even if that means that the client developer has to deal with some unwieldy interactions with multiple APIs where they're getting more data back than they need, those kinds of things. The best driver for getting more data into the graph is just to make it really easy to get data into the graph. And that takes work, right? That's the platform part of GraphQL. That's why many companies have a GraphQL platform team. That's what we're all doing.

Richard Moot: And just for anyone who's listening here who might not be familiar, could either of you give a quick explanation of what is meant by a federated GraphQL or a federated schema?

Michael Watson: Federation's near and dear to my heart, I actually started with the Apollo team back when we first announced it. Well, I started with Apollo team before, but when we first announced Apollo Federation, which was the early version of really what we're talking about back in 2019, really when you're talking about federated GraphQL, what federated GraphQL really is how can we take multiple GraphQL schemas and compose them into one shape and then be able to take an incoming request and then break that into the execution across multiple GraphQL APIs. So really what you do is you're adding in some metadata into your GraphQL schema. And this is really like I'm identifying this thing, this order, it's an entity. And what you're able to do is in that composition, all of that metadata is really coming together of here's those connection points between those entities and then here's where those entities live, those distinct URLs, service clusters, whatever they may be.

And then your modern GraphQL stack is really, you have some graph router sitting in front that's able to take an incoming request and it generates what we call a query plan. And that's really, I think of it as like SQL explain. It's a plan of based off this operation, we're going to execute across these downstream services in that. And it gives you a very structured order, this is exactly how it's going to happen. And it's also nice to see, like Alex was saying, if you don't have that one field in there, you don't see that hop, right? And then you add that field, then you see the query plan add that additional hop, what that really is, it's trading off the code that we would be writing by hand, that optimized code and maybe a BFF backend for front end. And it's really replacing the form of a generated query plan from a structured algorithm based on that composed schema.

So that's really Federated GraphQL. And the thing I love about it too is it gives you the flexibility to kind of go into whatever architecture you have, whether you have microservices today or maybe you have a monolith and you want to start splitting off parts of that monolith to maybe move a little bit faster before you get to two. You still have to have one. I always say that, and it's very quickly that you might be building the one you're like, oh, we need two and more right away. And I always encourage that. I think it leads to a quicker development cycle.

Richard Moot: And it also seems like it would give a lot of benefit. I know that we've seen this here at Block is that when it's federated that teams can own their part of the schema more easily and more readily. So we own this part of the federated schema. And so it's not like you're having to defer everything to say the GraphQL platform team and owning that entire interface. They're just like, Hey, we've created this system and your ownership is over here, and we just ensure that everything gets stitched together.

Alex Hancock: I think the reality in most organizations beyond a certain size is that different core objects that are important to the business or the organization have data from multiple teams, from different groups of people inside the organization that need to be contributed to the same entity, the same business object. And the way that happens in technologies that don't have something like Federation is often really messy. How many times have all of us seen REST APIs or Protobuf APIs where there's a prefixed version of the same object with 90 different prefixes across the company, something so and so is a version of a merchant or so-and-so's version of a payment. And then the client developer has to look at all those and kind of figure out, well, is this the same object? Are they talking about the same thing or is this something different? Federation just it's a new approach that wipes all that off the table and there is a payment object and everybody can contribute the fields that make sense for them to contribute. And there's a merchant object and everybody can contribute the fields that make sense for them to contribute. I think it's a shift in the technology that actually more closely models the real concepts that happen that exist in organizations. That's really helpful.

Michael Watson: You're giving me nightmares for my past, Alex. I was at Microsoft before Apollo and I worked with a lot of O data implementations. If you're not familiar with O Data, they have a schema version for every model or the entities you define in it just so people can have different representations of the same entity. But that's actually one of the nice things about Federation. Also, we talked about being able to own your own portion of the graph. Federation also has the concept of entities being multiple representations. So one team, one org might look at an order a certain way. Another part of the organization might look at that same order entity, but through a different set of key fields. And that's very common in enterprises and businesses that have been around for a while because you've adopted new technologies, you've maybe acquired a couple companies over time, that growth, that change over time, a lot of people talk about is technical debt. I don't like the word technical debt. I think them as technical assets and it's how do you unlock them? And that's why one of the reasons I really love GraphQL is you can modernize that legacy service in your federated architecture and now you're opening it to all the client developers. So I remember with O Data, if you were a C sharp client developer, there's a lot of nice to haves in there. You're building a React app. Well, half those nice to haves just disappeared. And what about them and what are they doing? But with a federated approach, you can expose those various different APIs, whether it's in C Java, whatever it is, there's a GraphQL library for that that you could bring together into a federated architecture.

Alex Hancock: Yeah, it's definitely a really helpful advance in the API technology. And I think Federation's kind of unique in my view as well, in that it is a benefit to using the GraphQL ecosystem broadly that Federation exists. And I think the reason it exists in GraphQL comes down in part to the underlying design of GraphQL, the field specific nature of GraphQL kind of makes something like federation possible. But this concept of merging multiple different data sources into a single consumable API for the client and merging their schemas in a logical way, that the big picture of what Federation does, I think is something that I have to believe that that concept will be replicated in other API technologies. I think it started in GraphQL in part because GraphQL’s really, really good at enabling it, but it's kind of a differentiating factor for GraphQL that Federation exists. Nothing like it really exists at scale that I'm aware of in other API technologies. So it's really nice.

Michael Watson: Actually Open API specification just released last year. It's called Arazzo. I might be saying that wrong, but that is a spec where they're trying to be able to compose multiple open API specs together, but that still doesn't include what is that router thing that's going to actually orchestrate those requests. It's just more of here's a semantic of how to describe that. That's really what Federation started almost six years ago now in the GraphQL space and is starting to make its way towards the actual GraphQL spec.

Alex Hancock: That's cool. It's bound to happen. It's just a matter of time that it'll make its way out of the GraphQL ecosystem.

Michael Watson: A hundred percent.

Richard Moot: And I'm super thankful for it because I mean, Alex can keep me honest on this. That's a large reason or way in which we were able to offer up our public GraphQL. We initially started with an internal GraphQL building that out, getting all the data connected, and then it was a matter of like, Hey, we're just going to create a variant of this schema over here, and then this is the public version or the publicly accessible way that you can interact with us. And there's not this huge wall of separation between all of this stuff.

Alex Hancock: Yeah, the code that powers the public API, it's just a smaller GraphQL API that is a subset of the organization's giant internal Graph API, and we've talked about how that works using the contracts feature from Apollo and everything. It's a really, it's a natural fit and I think something people commonly do because it deduplicates the code. The code that powers the public API is just some of the resolvers in the overall graph. And that's a really nice pattern, right?

Michael Watson: Yeah. And I would say it's extremely common. I mean, us at Apollo, we do have a public GraphQL API, but five years ago we didn't. And we started with our internal API. I mean, I'm looking at our stuff right now. We have 16 different GraphQL servers that make up our federated GraphQL implementation, and then we create a sub slice of that schema, which is our public API. I know GitHub does the same thing. Their API is like 300,000 lines or something huge. But I've talked with developers there. Their internal is 10 times that size. So it's very common to have what is the internal GraphQL API, and then how do we create a slice of that of what is the functionality we want to offer out there to the public.

Richard Moot: So now I'm kind of curious, Watson, because I feel like being at Apollo, you probably get a more unique view into this, is that the typical progression that is many companies have been seeing of building up a really robust internal graph and then eventually just parsing out slices? Is it also basically baking something in on the internal and then figuring out, okay, how do we actually then push this into the public graph? Is that a more common development pattern that we're seeing?

Michael Watson: Yeah, so really there's this things grow to a size and then people want to break them apart. But when you go from internal to public, it's like you get this level of comfort with your internal GraphQL API, where someone asks the question of, Hey, what would it look like to do something like that? And typically the teams have already built something into their internal API that actually gives them what they want. I think of the most common I've heard is people putting what we call it a schema directive, but this is the metadata you add into your GraphQL schema and they have it as pre-prod and basically the server that they run, if it runs in production environment, it automatically strips out anything that pre-prod directive on it. So it's very common for people to have maybe some directives that are custom directives internally and then they strip those out.

I mean at internal is also a very common one inside of there. And the really nice thing about GraphQL is you have a whole visitor API that allows you really to manipulate change to whatever you want in that schema in a very nice ordered structure. So I always hear about the build versus buy, all this different type of stuff. I think one of the reasons GraphQL got so successful is because everyone had that flexibility in the early days with early adopters, if you really needed to figure something out or change saying in your schema, you actually could do that pretty easily. I mean, I even think of how we name things, the way we name things changes over time. And that's actually something that you can have a lot of flexibility in what we called it internally. We don't want that to be what it's called externally. And you can actually have that change is really more of a build script or something that happens at a compilation step before you actually run that server in whatever environment

Richard Moot: You're singing to the things that I love to talk about, because one of the things is I sit on our API design group that comes up with the API design standards, and the most common thing that I'm doing is trying to rename things for public consumption because we have a lot of internal names for things, and then I have to spend a lot of time with folks of that's not what other people are going to understand externally because they don't know what this type of resource is. And it also has five different meanings outside of the company. So that's definitely exactly the types of things that I think about day in and day out.

Michael Watson: I think of all the fun little names and code names and things we think of as engineers as we're building the initial things. But then when you're like, oh, how do we get usage of our API? It's like, well, we got to name things that make sense to where those developers builders are coming from. Inside of that.

Richard Moot: The amount of time that we spent just on trying to figure out the name for our square terminal API, even though it is terminal, it's for doing payments, but we endlessly debated that if we call it a terminal to developers, they're going to think that we're talking about the terminal that they're using on their machine right now and not the one for taking a payment.

So one of the things I'm curious about with the federation, and I feel like this is probably related, but I really want to shoo in a plug for composite Schemas and its relation to making sense in the organization around federation, I'd love to just have you tell us more about Composite Schemas and the working group and all that stuff.

Alex Hancock: Yeah, I'm really excited to see this. I think the Composite Schemas Working group was something that, my understanding is it ran for a while and then it paused and there actually wasn't great alignment on how to do it and how to have this concept of emerging GraphQL schemas be an official thing in the GraphQL spec. And then after the folks at Chili Cream worked on GraphQL Fusion was an alternative to Apollo Federation. And of course Apollo has the very developed federation spec that's been used by a lot of people for a long time. It's the best example of this idea in real practice. After those things got more mature, it was like, okay, well now we can all kind of see how this is going to come together into something that makes sense for the real spec. And I'm really excited about that because I think the federation idea of combining many small GraphQL APIs into a larger GraphQL API is such a good one that it makes sense as something to bake in as a primitive in the official GraphQL the standard. And then once that spec is there, we can all get lots of implementations of these core concepts like Schema merging, schema composition in all different languages, really good tools for taking an operation and generating something like a query plan that will go make request to multiple GraphQL servers. All the good bits that make up the Apollo Federation implementation just leveled up even more considered industry standard. Lots of implementations, lots of languages, lots of flexibility to move between different tools. It's going to be such a good thing for GraphQL. So I'm really excited.

Michael Watson: Yeah, I couldn't agree more. I mean, we've always been big believers of Federation. That's why we put out Apollo Federation, and we've also been very close workers in the GraphQL Working group, even before Composite Schemas. It did pick up and kind slow down. One of the things that I think is really important to say, Apollo has always been very committed to some global standardization of GraphQL Federation and within the GraphQL community, I've always been one of the people saying, Hey, if GraphQL continues to be a thing, everyone in GraphQL wins. That's what it is. I think standardizing this is extremely important. We've kind of always been the leaders of federation's the way to do it. This is the architecture. And when the opportunity came up for us all to start coalescing together on a larger effort, the Composite Schemas working group, we jumped right in.

I think there's, if you look at the notes in the working group, the agenda, there's been a really long standing inside of there. I mean all of 2024, there's monthly meetings from the primary working group, secondary working group. We have to have different time zones making sure everyone who wants to be included. If you're someone that's like, Hey, I want to be included in this too, you can go to the composite schema working group, GitHub repository, and you can just add yourself into the next agenda. Anyone is involved. And I love also seeing the collaboration. I like to think of us as, we've kind of been the leaders in the Composite Schemas working group, but the Guild is there. They have been great stewards of open source GraphQL projects and have done a lot of stuff. If you're using CodeGen, you're using some of the libraries they maintain along with a lot of other stuff.

Netflix, they created DGS, which is their Java GraphQL server that they use internally. They're very active in the group Chili cream, all the learnings from Fusion, they're active in that group. Benji with Graph File, Benji's, Benji's, an OG in the GraphQL space. And we're so lucky as a community to have Benji with everything he's kind of brought to the table. But it's really great to see it evolve to this. I was very lucky to work with all the early federation deployments. I actually, that's how I met Alex. I was one of the Apollo people in the room with Square in the early days talking about GraphQL. And it's been really cool seeing kind of these production deployments grow and continue down this path. So I think the standardization is absolutely necessary for the long living of GraphQL and where we're all going. And it just, it's really been great to see the growth, and I'm very excited for when it finally gets merged in. But it's very important to note when you're bringing something like this into a specification that has longstanding history, you got to be very thoughtful of how are we naming things, all of those things. We called it Apollo Federation, but now it's Composite Schemas Working Group. That's a great example, right?

Alex Hancock: Yeah, it's fascinating to watch the meetings, the YouTube videos of the meetings are really interesting. And the technical depth that goes into some of this decision making, it moves slow for a reason. The spec moves very slowly for a reason because you have to consider very carefully when you make a change, how is that going to impact the rest of GraphQL? And sometimes an idea might seem great for even the first month that people think about it and then you realize that it breaks some core thing and there's really no way around it, and you need to go back to the drawing board and come up with a different idea. But the thing I've really enjoyed about watching the new round of meetings that have been going again with the composite schema working group is the Apollo folks that attend have the most practical real world experience with an implementation of this that's been used thousands of other times.

And they've seen the edge cases. They've seen all the edge cases. So you have something you want to do with one of the directives, inaccessible or whatever, and thinking about how you prune things out of a schema or how things merge. The semantics of what happens when you try to merge two bits of schema. And there are these long discussions about what happens when one very specific thing happens and how we want it to behave in open source standards. So they're taking their time, they're doing it right. We're going to get something that's really high quality as a community as a result. And I'm grateful to everybody who's doing that work because it's real work. It's technically deep, it's to be celebrated.

Michael Watson: Federated interfaces is no joke. That's really complicated when it gets into how's that thing represented? Multiple, because we use interfaces for everything and just general coding practice with when we're building abstractions. And I'm really happy that there's a lot of very smart people. I'm not one of those people on that group smarter than me figuring those things out and getting to have a very good, rich conversation. I'm glad there's also representation from multiple enterprises, companies, you can see various companies attending those working groups to make sure their edge cases are included in that. So if you're thinking is mine in there, I'd love to have you get involved in that group.

Richard Moot: Yeah, now is the time.

Michael Watson: Now is the time.

Richard Moot: Awesome. And for somebody like myself who's not familiar at all is what the composite schema working group, is it working on a spec similar to that of say, open API is for REST of having a formalized pattern or thing to adopt when doing Federated Schemas?

Alex Hancock: The way I view it is like an open source industry standard version of what Apollo Federation already is, right? Apollo Federation is specific to a spec provided by Apollo, and this is just the open source equivalent that will carry on a lot of the concepts that exist in Apollo Federation and make it better, make it more general fix a few things that I'm sure y'all have probably wanted to fix in Federation for a long time, and now that there's a chance to do an open source standard, it's just the open industry standard version of something like Apollo Federation.

Michael Watson: A hundred percent. And I'd also say a reason we've kind of been a core leader in the composite schemas working group is because we have so many companies we've worked with where we want to make sure that composite schemas as we move forward with that, it's not like Apollo Federation doesn't work with that stuff. We're fully committed of aligning everything that federation is along with that spec. Now, what I think will for sure happen similar to what Alex was saying, is we're going to have a standardization that happens and then we're going to get a couple different flavors that have feature specific or things of nice to do this that's from maybe a vendor or another open source project. And that's the beauty of GraphQL is there's always been that It's not like every GraphQL server all works the same. There's definitely some little things in some GraphQL servers that they've added some nice things.

I know there's some things in Java's GraphQL server libraries that those directives I talked about at pre-prod and stripping things out. Some of that's actually already built into that GraphQL server that's not part of the spec now. It's a spec compliant GraphQL server. It's just adding some nice features, things on top of the spec. So I think that stuff will continue. Defer is a great example where we talked about progressively loading things in there, but how that router handles that execution, what's inside of there, there's going to be the basic description that's coming from the spec, but there's going to be kind of the different implementations. And that's great about it is that's how you make everything better. You bring the whole industry forward to that next level. So I love it.

Richard Moot: And I guess the final thing I'll ask on this to, and again, forgive me because I'm not super familiar, but I'm assuming that part of the main benefit is that as the spec is more well defined, more well shaped and then more well adopted, that it becomes easier to sort of add in. Say I want to federate another public graph into my own graph of like, Hey, I want to pull in GitHub repo data in a uniform way. It's suddenly going to work way easier because it's following the same exact patterns and specs that we're expecting. So it's not just on my internal stuff.

Alex Hancock: Exactly. It's about the ability to have many implementations of something like a router, and it's also about having many sub graph, many GraphQL servers out in the world that all adhere to the same spec for how they can be merged with each other. And so yeah, it's just getting everybody in the industry to align, and it really brings that concept up to the level where it's officially included as part of GraphQL, which is cool in a real boon for GraphQL as a technology, I think.

Richard Moot: So theoretically, somebody out there could eventually just build one graph to rule them all just be ultimate federated graph.

Michael Watson: Yeah, that's always the dream. The one graph, one of the things I also think about with, you just mentioned one graph, there's kind of like, I remember Apollo even talked a little about this stuff. You have one graph and then you have multiple representations, and that's kind of like an ideal state. But I think when you get into the practical implementation of companies, you got multiple graphs internally, and it's just like there's teams you've never talked to. They don't even know. I mean, some of these companies are just so large. I'm lucky at Apollo we're not that large, so I can go talk to a lot of these people, but I mean, I'm sure even at Block, you have offices all around the globe and developers everywhere. Those developers don't always necessarily get the chance to interact, and it's totally okay to have those multiple graphs. And the great thing about having that standard is the day you want to click them together, no problem. It's there. It's ready to go. You're prepared for whenever that day comes, so you don't feel like you have to jump to that, but it's always an option.

Richard Moot: That's awesome. Well, with that, I think we can go ahead and wrap things up for today. I want to give a big thanks to both Alex and Michael for joining us. I feel like I've learned so much already and I just want to go build stuff. I mean, obviously I'm going to go build stuff with a Square GraphQL API, but I want to stitch it together with others now. But again, thank you both for joining us Watson. What would be the best place for people to go and learn more about what Apollo is working on and what they're offering?

Michael Watson: Yeah, yeah. The best place, if you went to our website, of course, there's a lot of stuff there. I'm a big fan of our docs. I think we have great documentation around that Federation spec. If you wanted to learn anything around Federated GraphQL, that's a great place to start. The other thing I'd say is our tutorials. We actually have some really good tutorials that are all free, so if you even just wanted to learn how to start doing some GraphQL stuff, anything in federation that's there. And then also there's GraphQL.org. There's a GraphQL Discord that it's a great resource for you to go into where it's just a lot of the community members all talking together. Those are some of the official GraphQL channels that are inside of there. And of course, if you really want to get in the composite Schema working group, if you go to the GraphQL GitHub, you'll find kind of everything in there. That would be a great place to jump in.

Richard Moot: Fantastic. Well then I guess I will just plug that if you've got a project with Square, we'd love to hear about it. Reach out to us on our Discord, which you can also find over at developer.squareup.com. Or you could reach out to us on X at square dev, and be sure to check out our Square GraphQL API. Yeah, if you're going to be building from scratch, I think it's a great place to get started. And so feel free to test it out. Let us know what you think and keep building and we'll catch you next time.