GraphQL at Scale - Panel Discussion

It's good to be here. I hope you're all doing well. It's been an insane conference so far and it's been so much fun to watch from the sidelines, but it's my pleasure today to be here with all of you to host this panel on GraphQL at scale.

But first and foremost, what do I mean about GraphQL at scale? I mean, scale can be a lot of different things, right? There's technical scalability, so accommodating a larger technical load. There's product scalability, accommodating more products or more product variability. There's team scalability. There's expanding your team in a variety of different ways, whether that be geography or size or so on, so forth, skill sets and so on, so forth. I mean, there's a whole lot more ways to scale than what I've even just mentioned just now. And in fact, I was speaking to Uri before the conference and he told me, Taz, if you start to scale up your hair, just like Uri's hair, I can start to understand GraphQL a bit better. Well, I tried and I still don't get it. I still don't get it, Uri. So, I'm afraid that one doesn't work so well. So, you got to give me another tip, man, because that one's not working out so well. But anyway, for me, what I've found is that GraphQL can have a pretty profound effect on how you scale. The technology decision itself can affect how you scale in all those different ways that I mentioned, and we've managed to get some of the top minds on GraphQL from across the entire galaxy here for you today to talk to you about different ways you can scale GraphQL.

So, without further ado, it's my sincere pleasure to introduce you to our panelists. So, Metin already introduced them, but I'll take another stab at it in introduce everyone again. So, first and foremost, Dan Schafer, if I can ask you to give a little wave, Dan. He's the GraphQL co-creator, Facebook engineering director. We have Danielle Mann, engineering and design manager, helping build things for GraphQL at Apollo, currently working on the Apollo Explorer. You get a wave, Danielle. Nick Schrock, the GraphQL co-creator, founder of Elemental, working on Daxter, ex-Facebook engineer. Gonna get a wave, Nick. And last, but certainly not least, Tanmay Gopal, CEO and co-founder of Hasura. He is a stack overflow powered full stack developer's area of interest and work span React, GraphQL, Node.js, Docker, Postgres, and Kubernetes. He is passionate about making it easy to build complex things, and is the instructor of India's largest massive open source online course, The Introduction to Modern Application Development, with over 250,000 students. Can we get a wave, Tanmay?

And I think maybe my first question, how do you remember all those names? I mean, I can remember like three names, but 250,000 names, that must be a really long attendance session at the beginning of all your lessons. That's a lot of people. Yep, yep. Just the online nature of the course really helps with that.

It's good to be here. I hope you're all doing well. It's been an insane conference so far, and it's been so much fun to watch from the sidelines. But it's my pleasure today to be all of you to host this panel on GraphQL at Scale. But first and foremost, what do I mean about GraphQL at Scale? I mean, scale can be a lot of different things, right? There's technical scalability, so kind of accommodating a larger technical load. There's product scalability. There's accommodating more products or more product variability. There's team scalability. There's like expanding your team in a variety of different ways, whether that be geography or size or so on and so forth, skillsets and so on and so forth. I mean, there's a whole lot more ways to scale than what I've even just mentioned just now.

That's awesome, dude. Well, it's a pleasure to meet you all. And it's a pleasure to talk to you all about GraphQL at scale. So I guess, without further ado, let's kick it off with a question.

So as I mentioned before, I think GraphQL is inherently a technology of scale. I believe it was formulated at Facebook when scaling their data layer to accommodate multiple device form factors. So what aspects of GraphQL drew you to it when addressing those types of challenges of scale? I guess we can start with Dan.

Yeah, I think the way in which it scales is sort of interesting, because it scaled differently over time, sort of in its evolutions at Facebook. Where the original problem of scale, I think we anticipated the need for multiple clients, but it wasn't even multiple clients at the same time. It was actually the scaling of clients that change over time, where we knew that the newsfeed that we wanted to ship in, the original proto version of the native Facebook app in February 2012, was going to be different than April, was going to be different than June. Just the speed of evolution was going to change. And so it obviously has proved very helpful in having multiple clients at once, but even just scaling within a given client, the ability for a client engineer to say, hey, I'm going to add this feature now, and they don't have to version a server. They don't have to potentially make a server change if the data's already there because of the graph nature of it. I think that was probably one of the original scaling factors that I think didn't necessarily draw us to it, but drew us to create it.

I think one of the things that drew me to GraphQL, especially from the scale aspect, was I think especially over the last few years from what I've seen in the ecosystem is that there's two aspects to scale that are particularly important with GraphQL. The first is this technical aspect, which is that your technology team is scaling and there's a bunch of work that you're doing that is going to be repeated across all of these engineers. Whether they're consuming the API or building the API and whatnot. And GraphQL really creates a formalism for people to interact when they hit those levels of scale. You realize that, Oh, well, we need to have something like fragments, but then turns out when GraphQL has it, you need to have type safety and GraphQL has it as spec. So those technical aspects, so you realize that you're making multiple API calls, you should just be making a better batch API call, and GraphQL is in a way this amazing batching technology. And so that aspect is exciting for sure. But I think there's another very interesting aspect of GraphQL at scale. And I see this, especially in enterprise with what really appeals to people about GraphQL, is not so much the technical awesomeness of what GraphQL lets you do, which is let's say performance and type safety. Okay. To a degree, maybe type safety, but also not the performance aspect of it and whatnot, but more the metadata aspect of it, which is that this aspect of saying that we have this ability, or we have this formal way or this way of specifying our API and exchanging information about our API. And this is more of an organizational human problem of scale rather than the technical aspect of scale, which is saying that we should have really just done this right the first time. We should have had APIs, we should have documented them, we should have had open API specs or whatever. It should have been better, but it's not. And for them, the appeal of GraphQL is, oh finally, yes, this makes sense. We should have this Explorer tool, GraphQL.

And in fact, I was speaking to Uri before the conference, and he told me, Taz, if you start to scale up your hair, just like Uri's hair, I can start to understand GraphQL a bit better. Well, I tried, and I still don't get it. I still don't get it, Uri. So I'm afraid that one doesn't work so well. So you got to give me another tip, man, because that one's not working out so well.

But anyway, for me, what I found is that GraphQL can have a pretty profound effect on how you scale. The technology decision itself can affect how you scale in all those different ways that I mentioned. And we've managed to get some of the top minds on GraphQL from across the entire galaxy here for you today to talk to you about different ways you can scale GraphQL.

So without further ado, it's my sincere pleasure to introduce you to our panelists. So Metin already introduced them, but I'll take another stab at it and introduce everyone again. So first and foremost, Dan Schaefer, if I can ask you to give a little wave, Dan. He's the GraphQL co-creator, Facebook Engineering Director. We have Danielle Mann, Engineering and Design Manager helping build things for GraphQL at Apollo, currently working on the Apollo Explorer. You can get a wave, Danielle. Nick Schrock, the GraphQL co-creator, founder of Elemental, working on Dagster, ex-Facebook Engineer. Gonna get a wave, Nick. And last but certainly not least, Tanmay Gopal, CEO and co-founder of Hasura. He is a Stack Overflow-powered full-stack developer with an area of interest and works on React, GraphQL, Node.js, Docker, Postgres, and Kubernetes. He is passionate about making it easy to build complex things and is the instructor of India's largest massive open-source online course, The Introduction to Modern Application Development, with over 250,000 students. Can we get a wave, Tanmay?

This makes a lot of sense. Why don't we have it? Why haven't we have it? We should have built in documentation about at least the spec, if not the usage pattern of the API. At least the spec of the API should be documented and should be a part of the thing. And what I see from those kinds of users is that they don't really care about GraphQL, the API method. They care more about GraphQL, just the metadata. They're like, you know what, at the end of the day, in fact, especially in enterprise, I would rather not consume a GraphQL API. I would rather consume a REST endpoint or a GRPC endpoint, something that we have the rest of our organization tooling around, because we don't have so much tooling around GraphQL. And so we have so much tooling around so many other things.

Is that they really kind of just fall in love with that metadata, that graph idea that ultimately all of your entities are related in some sort of a graph. And they really liked that aspect. So I think the organizational scale aspect of GraphQL is very, very powerful, right. And is also kind of very accessible to people. So that's kind of been two very interesting things to me about GraphQL at scale.

Yeah. That's super interesting. Yeah, no, I'd like to build on that. Because I think I would have a unique perspective since I was the one who built the first prototype of the thing. And to Dan's point, it was not the fact that it was multi-device. It was kind of the realization of one, up until that point, my career at Facebook had been spent effectively being one of the people who really took it upon themselves to save our application monolith, which bleeds into another subject that we're going to get into later. But we had done a ton of work to build these abstraction layers, and we had actually horizontally scaled our monolith across hundreds of engineers. And then, kind of started to see what would happen with mobile. And what was relatively clear is that you would have mobile engineers going up into the rest, going up and building custom rest APIs. And it was fairly self-evident. Maybe it wasn't self-evident, but I believe at the time that that would've been a disaster. It would've been like the mobile engineers like Visigoths invading Rome and burning down the monolith we had saved. So, really, the critical thing here is one, it was vertically integrated on top of an existing abstraction that was working. So, the GraphQL layer on top of the internal Facebook abstraction was very thin. That's why I was able to build the prototype so quickly, not because I'm some amazing engineer, but because it had stacked on top of work that a whole team had done for like three years. And so, that was one aspect. And then it was really about having a better relationship between the different types of engineers in the organization. Because you could have server side engineers publishing schema in actually a pretty constrained way to mobile engineers that would then consume it. And that turned out to be a very healthy, well, relatively healthy relationship that ended up scale. And I think dramatically better than the inevitable. Because like, this would have been something like move fast, break things, Facebook culture, would have just like spawned, like I said, like an invasion. And I think would have been really challenging to manage. Ironically, not the dependency era, I think in like non Facebook usage of GraphQL is inverted from in Facebook. Is graphical word, but Facebook had a concept of like, yes, these are the objects, you know, call them, and obviously talk more about that. Cause I was, you know, his almost baby, but like it is, you know, they existed and we'd had them for years and they were almost de facto and GraphQL was like, okay, well, we have this concept of the graph.

The graph is great. These things have relationships. We understand how to fetch them. We understand how to connect the edge between them. If only we had this on mobile and listening to Tom and talking to, with folks on the outside, it's actually very often people are like, oh, GraphQL makes a lot of sense because I really want that representation. And you almost like you realize how valuable that representation is because it's the representation that makes GraphQL feel most natural. Well, the reason this is a representation that makes GraphQL feel most natural is because it's the representation we had and it's almost this inverted dependency.

Yeah. I think one of the things that really draws me to GraphQL is the idea that once you define what your graph is, you don't have to know exactly how people are going to use it for it to be really useful to them and the right thing for them. One of the things that originally drew Apollo to GraphQL was the idea that it could maybe be a technology to connect many different types of databases together and it's just a really powerful thing to be able to define something that can be used abstractly by any different number of clients because the types of things people are building now are just way beyond what they were even 10 years ago. And you can't always predict how people are going to want to use your API or even keep up with it. So it's best to build flexibility from the get-go.

Danielle, I have a question for you on that front. In Out in the Wild of GraphQL, because I actually don't have too much visibility into it, do you see people building GraphQL schemas that are specific to views? We used to call them view models. Or do you see more GraphQL schemas that are kind of like the core data model?

That's a great question. I mean, I think people do it all sorts of ways. And earlier on, I think our recommendation was that you should design your schema for views because that's going to be the most efficient thing for your apps. And I think when you are building an app, your schema should correlate to it because that's the best thing for the application. But what we've been talking about lately, especially in Apollo, is you should use GraphQL to be the way that you define your data model for your company. And instead of having your data models and lots of different microservices in different places across many different teams, you know, like dedicated teams building the graph, have them define the data model, how every microservice team figure out how they fit into that and build into that. And then your data model can be, like, if you bring it up to the API layer, then it cleans a lot of things up, and it can just be directly what the clients use. Yeah. And it makes client-side caching dramatically more straightforward. Yeah. And also reuse. Sorry, go ahead. And also reuse. One of the things that are sort of amazing is after we define the user object within Facebook, someone went out of field to user, and then the next person came around and was like, oh, shoot, I'm going to need to be able to show, you know, the users cover photo. Oh, it's already there. Cool.

I'm ready to go. Exactly. Yeah. I think from, to kind of, to answer, to take a stab at Nick's question, right, I've seen both. I've seen people kind of really, like, structuring GraphQL around views. And then, especially for people who are kind of going towards the event-driven microservices kind of style of things to kind of start thinking of, like, GraphQL is the Q in a CQRS kind of workflow, right? So that's, that idea has, that idea seems to have some weight, some momentum. And then I've also seen, of course, ideas where people like having GraphQL kind of describe or, or using GraphQL and kind of the core data models. And I think it kind of boils down to the use cases that people have for GraphQL, right? And I think the, like the client-centric use case, which is perhaps the original kind of the OG use case for GraphQL, right, which is the better client API specifically for front ends, right, to communicate with back ends. But then there's also kind of that platform centric use case, right, which is the use case of like, well, I mean, I don't know what 10,000 models I have, and I want a better way of kind of understanding my models and what methods I have on my models or how to query my models and mutate them or whatever. And so there's, there's both. But you know, it's, and I think like the trade offs and like what people want out of it and what people want to optimize for kind of depends on, you know, what they're really solving for with GraphQL, right, or what is that kind of problem that they really want to attack, whether it's a back end for front end kind of problem that they have so many microservices and they want a better API, or whether it's kind of like our API is just a mess and it's horrible for humans to browse. And how many types are in the Facebook GraphQL scheme of these days? I don't know, but it's got to be five digits. I would have to check. It's not a real scheme until it crashes GraphQL. That's what we used to say. It was very, very apparent where things were quadratic and graphical. I guess these days it's a matter of if you can load it with an Apollo Explorer, if it's going to load or not. But I mean, like I know, Daniel, like, you and your team are working with massive teams and massive graphs, and you're building a lot of tooling and infrastructure to really support all of those teams at scale. So I guess my question is like, essentially, what I'm hearing a lot from the panel so far is that it seems to be more of an organizational scalability type of challenge. It's how do I scale across more engineers, and how do I make the actual domain modeling of my graph kind of self-evident to adding more engineers to the team? You mentioned that that's something that you recommend at Apollo. And I'm just curious, in terms of the tools and the infrastructure that you're working on there, is there anything that you offer within that tool set that can basically help with those types of things? Well, I think the big thing for scaling a graph across the organization that we offer at Apollo is Apollo Federation or Federation in general. I know there are a lot of opinions out there on the right way to build a graph out of multiple subgraphs, and there are many options, but the one that we've been developing is really like to come back to that idea that I said where your API and your graph should be your data model and everything should be feeding into it. Federation is really meant to help you do that because it helps you kind of define entities in certain places, extend them in other places, define how these partial schemas relate to each other. And that's the way that we see organizations being able to scale their graph because you could imagine kind of one service per team in a big company where everyone is kind of federating into the overall picture. So what we're trying to do is build tools to help you use federation and follow a model like that where you can really scale those things effectively. But there, I know that there are probably even on this panel a lot of opinions on what the right way to do that is, so I'm curious to hear from everyone else. Yeah, Tanmay, have you found any sort of ways to be more optimal in scaling?

I think, again, it kind of boils really to the, it boils down to the use case of like what you're trying to generate, right? Like, for example, again, if you have this situation where you are, we genuinely have this situation where you have a bunch of mobile or front-end applications, and they've been querying 20 different microservices, and it turns out that all of these services do actually have a lot of interrelated data, right? And you want to create and operationalize a process of maintaining a central API that allows these front-end clients to consume that API, right? And so now you can have different approaches of building that out, right? And I think, again, like it depends on the organization. I've been a little bit skeptical of automatically assembling that federated thing because it'll be interesting to see how that works because it kind of goes almost against the idea of microservices itself to say that, well, we wanted to make these teams independent, but now we've made them dependent again. And they're kind of talking to each other like they should have been perhaps but outside a usual channel of code. And so maybe GraphQL or a federation approach with GraphQL is a way to solve that problem again. But of course, there's more traditional ways of solving that problem, which is just go back to everybody goes back to Monit or you maintain a GraphQL gateway in the center that some team maintains or whatever. So that's kind of one kind of problem that you have. But I think this idea of saying that we should have when you think about like all of the APIs and all of the services in enterprise, not all companies in the world are Facebook, obviously. And they all have very different problems. In fact, traditional enterprise, it's very weird. It is not at all like a tech giant like Facebook. It's extremely different. There's a very, very large number of teams in LOBs like lines of businesses that are catering to very specific customer segments. And for them, the APIs that they're producing, the reason why microservices caught on in the first place was because for them, the APIs that they're producing have a very particular cognitive model around the API that they have. So now, if you suddenly say that I want all of the APIs in my enterprise, which is insane because it's not possible for this massive traditional Fortune 10, Fortune 100 companies to have like this. It is not the same API, they don't even have the same customer. I mean, it's insane across these different LOBs, right? And so here, if you're introducing kind of this idea of saying, well, let's all collaborate on a single graph. It's going to introduce more, an increased cognitive kind of overload on people in consuming that API. They'd be like, no, no, no, no. Please, I don't understand anything that's happening. Please take me back to the 10 endpoints that show me how to make a payment to a merchant and how to refund that payment from a merchant. That is all I want. I don't want to see this graph. So what problem you're trying to solve and what sections you're trying to maybe unify and why you're trying to unify them, right? Again, is it driven from a technical performance back-end or front-end type use case? Is it driven from a platform-centric use case of saying that, well, these 10 teams should have actually been one team and we should have actually had one coherent API. What is the use case? And that use case will kind of guide that different kind of federation approach, or whether you should even be using GraphQL or not, right? Those kinds of things will kind of come out of that, right? It's risky to say that there can be just one approach to GraphQL, because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we use GraphQL for and making that case.

What is the use case? And that use case will kind of guide that different kind of federation approach, or whether you should even be using GraphQL or not, right? Those kinds of things will kind of come out of that, right?

It's risky to say that there can be just one approach to GraphQL, because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we use GraphQL for, but GraphQL for and making that case. Yeah. Tim, I actually love the way that you framed that up about decomposing technical and organizational determinations, because, you know, I have very strong and polemical views on microservices. I think they're overused for sure. And, you know, the way that I think it actually ironically explains a lot of the popularity of GraphQL, because a GraphQL schema is your subconscious telling you that you want your monolith back. And if you want to assemble a set of microservices into a single schema, which in microservices speak would be a single bounded context, if you're kind of into that language, domain-driven design, in my opinion, if that feels correct, then what you have is a distributed monolith, and it should've been a monolith in the first place. And, you know, I think there's going to be this really interesting counter reaction. And you see it in systems, like out of Airbnb, there's a system called Viaduct coming out. At Twitter, there was a system called Strato, where they're actually moving compute back up into this federation layer. And that gives the client teams autonomy where somewhere they can push code where they don't have to talk to the microservice team. And I'm going to be really interested to see if more and more the business logic naturally moves to that, I think you referred to as a GraphQL gateway, maybe it'd be like a smart gateway or something, or to call it like the application microservice, then everyone will be willing to accept it. Whatever it takes. But in the case that you're talking about this separate lines of business, it's actually appropriate, I think, that a separate service and a separate GraphQL schema per line of business, because they are completely disaggregated, bounded contexts or schema. So that's where I'm at. It's a fascinating thing to see, because obviously not everyone who does microservices is an idiot. There's a reason why people feel compelled to do it. They can no longer horizontally scale their org. So I totally get that. So I'm trying to be less flippant on this. You have changed, Mick. This is a change. It all ultimately comes down to tradeoffs, as well. And the one that always comes to mind for me is this separation of concerns. Separations of concerns is good when the concerns can actually be separated, when you're like, hey, these two things can operate independently. And I think what I see Facebook sort of legendarily as a monolith, kind of. Newsfeed has its own back end. Timeline has its own back end. Search has its own back end. It is a monolith in terms of its business logic is monolithic. But in terms of some of, if you're trying to store stateful logic for Newsfeed, yes, that's going to be in a service.

Well, why is the business logic in a monolith? Because of feed. Because fundamentally, you cannot separate the concerns of the Facebook application, the app that you opened. Because you're in a feed, and you see a story about Nick attending this event, and you see a photo that I posted. And you see the fact that Danielle checked in someplace. And all of these sort of things that could presumably be independent services, they do inherently. You cannot separate those concerns. And I exactly sort of shared in a second, which is, if you've got 10 microservices, and they all have the same API, and everyone goes, of course these have the same APIs. Well, how did you actually separate those concerns there? If those 10 things fundamentally need to relate, if the interaction between those 10 services can't be decoupled, they can't be decoupled, and yet we chose to decouple them. And on the other hand, if you can decouple them, it's like, these two graphs are independent, I actually have no idea what value you would get by putting them into the same GraphQL API. That feels sort of like a false dependency.

There is a little more... I think sometimes reality ends up being a little... It's a little harder to say upfront, are we going to be dependent on each other, or are we never going to talk to each other? It's hard to say, right? What we've seen from people is where we've seen separate kind of LOBs, right, or lines of business adopt that, adopt kind of GraphQL, get very productive with it. But then suddenly this team realizes, oh man, there is some data that that team has, which if I had, it'd be amazing. And now suddenly they're like, oh my goodness, what do we do, right? How do we set this up together? We have to build some things. I wish we didn't have to build this, right? So there's a little bit of the natural dirtiness of life that gets in where things are not clear and people don't know how to do things that make it a little bit harder to think about what should be what upfront, right? Especially in teams, which, especially in teams where the organizational structure, promoted autonomy rather than collaboration, right? If you think about with microservices, what's happening is you're having organizations that promote autonomy. With Monoliths, quote unquote you have organizations that are promoting collaboration, right? It's two sides of the, it's the same thing, but a little bit different, right? So, so I think, I think that kind of complicates that it makes it a little bit harder for people to choose upfront, right? So there's some interesting things there. To Nick's point, though, one thing I'd like to add is I like our crazy idea or hypothesis is that there are some kinds of business logic that you can actually absorb into that GraphQL layer that is repetitive that maybe you don't have to repeat again and again, right? And, and for us, our gut feeling is that authorization, when related to data and caching, are two infrastructural, almost concerns, but still concerns that every single developer has to deal with, that could be brought into a common layer, right? So that's kind of the lens that we're taking. Whether it's not necessarily a GraphQL lens, but it's kind of a lens of, like, this is repeat work that we're doing across a bunch of people that maybe we can bring somewhere, right? Which is a type of business logic that can be made common across a large number of people, right? So it would be interesting to kind of see how that evolves, of course. I'd like to hear Danielle's thoughts on this, because I feel like, as a Apollo employee, you're dealing with the kind of aggregating microservices problem a lot.

Yeah, I think where the microservice and federation model shines is like close to what Tanmay said when you have different teams or lines of business that want to have autonomy yet have things that relate to each other and still want to be able to bring those things together. So, I mean, even inside Apollo, we build a big SaaS tool, we use federation, and we have this debate all the time, like, we have some microservices, but we don't have, you know, four teams working on them. We have two and we're like, why do, why did we split these things up? In some ways, we're creating more overhead for ourselves than is beneficial. But in other cases, you know, when you have another team that's entirely independent of you, that's running services that don't relate to you, you're not on call for them, you don't want to be responsible for them. Yet you still, in abstract, think that it's a good idea for those two services to go into the same graph. Then that's where something like federation, I think, shines and kind of enables you to contribute to the same overall thing, while letting teams remain autonomous and keep their own life cycles. So yeah, I mean, it's all like, it depends, right. It depends on what you're trying to do, what's right for you, how your organization is structured. Yeah, it's the messiness in humans. Awesome, that's fantastic.

And yeah, I think we can talk a lot more on this topic, but in the interest of the wider audience that we have, let's move on to a slightly different one. But maybe let's get back to this one before we end things off.

So in terms of the GraphQL spec, I mean, we're all here today because of GraphQL and we're all here today because of the GraphQL grammar and the GraphQL spec. And since the time I've been using GraphQL, it's remained mostly unchanged in terms of the core grammar. The core grammar was fundamentally what it was. But of course, as we keep applying more paradigms to that same grammar, we're starting to see a bit of an evolution in terms of the grammar, in terms of the spec, and in terms of how GraphQL is being used.

So I guess my question is that with more paradigms being added, essentially, what are you most excited to see in terms of GraphQL? Which paradigms are you most excited about? And in which ways are you most excited about seeing the GraphQL spec being applied to those paradigms? And I guess we can start with Tamay. I have a non-controversial answer to this question, which is that I feel like what I would really like is a GraphQL lite, which is a reduction of the GraphQL spec for some of those platform-centric use cases that I talked about, where what I would like to do is say, for example, get rid of, let's say, interfaces and unions, and kind of simplify that a little more. So that essentially the purpose would be so that what I would like to achieve is almost kind of a bijection or a mapping between any GraphQL query to a REST API. And I feel like that can't happen right now because GraphQL has more specific things. It's harder to achieve. Right now, it's a little more complicated, but simplifying that so that we can have like a mapping to a REST API model, I feel like that would be extremely useful to a lot of people who are looking at de-risking their adoption of GraphQL, because then what happens is that they have a lighter way to kind of enter GraphQL with a subset of the spec, but in a way that the rest of their existing tooling doesn't go to the dogs, right, so that there's like... that existing tooling can start to emerge and work, because there's just a tremendous amount of like inertia that the existing API tooling that people have and the tools that they're using and how they've gotten used to it, everything from to API management to error handling, right? Error handling is so confusing in GraphQL because you get partial errors, right? This is a problem that people just... Yeah. Sorry. No, it's not just. It's the forever skeleton in our closet. It's the 200 response problem, right? It's like everybody is used to... there's so many vendor tools today, where if you just plug that into your API, you kind of get like this tool that says, you know, this API is not working because the status code is 4xx or 5xx or whatever, right? But now with GraphQL, you can't do that. You have to kind of inspect the response. So now your vendor tool needs higher privileges to inspect your response. Now nobody's prepared for this because it violates all of their compliance, right? They're like, what? No, there's no way this monitoring tool is getting access to my response body. And so what they want is the return to a simpler world where they're like, well, no, you know, we had already done this. This problem was solved. So maybe... I'm not sure if this moment is even feasible or make sense, but it's just a random idea, right? It's like a random thought process of like, what would happen if GraphQL was maybe a little bit simpler on some things, or maybe simpler is not the right word, right? That that allowed kind of that intercompat or incremental evolution to happen from where people's APIs are today.

So that's a absolutely not a fair question. To be fair, I think a lot of the problems you're describing can be solved with software, software layers on top of GraphQL. So like, you know, like for example, the compliance thing you make, makes total sense. And the the so like, for example, if I was, you know, dealing with that problem, you know, I would try to distinguish errors that are like non ideal states in the application from hard errors, and then have a software layer that translates the hard errors to exactly 100.

Right, exactly. I don't think you need to change the spec to to solve that actually, 100%. You know, for example, you can also choose server side just simply not to support or to link to a search against using certain features, such as the bijection that you're talking about. So got it. You know, I think you we you know, we can solve that. And so completely agreed.

Yeah. Yeah. And I, the reason why I used I said spec is because I think those tools need to get a little bit standardized, right? Because what people don't want to do is they're like, wait, no, I don't want to build this software that will do this for me, right? Like I don't want another piece of software to maintain. I just want this to be done. Right? So you want to rescue our spec? I want to rescue. Exactly. That's the I would love to see continued work in errors. I mean, Nick and I were sort of laughing at it. I have a very distinct memory of a conversation where I was just like, what do we do with errors in the spec? And it's like, well, the way that we handle errors is bad. So we can put that in and that's a bad idea, or we could guess and try and put something else in there or we could leave it relatively underspecified. And like, I think it is, it is a really hard problem. And if, you know, evolution in the community, a better idea, like I, I don't like how errors are handled right now. I hope we come up with something better. And the community is innovative. Like I actually think that Saatchi's pattern, Oh yeah. The union era pattern. It's just like, what's that? And I was like, why don't we think of that? But thank God we had the generalized abstractions to support that. That time I wants to get rid of, no, I'm just kidding.

One thing that I'm really excited about is AdStream and AdDefer. Where I feel like those sorts of, you know, streaming responses is something that, you know, we, I think it was probably 2013 when we realized, okay, yeah. If we're vending 10 feed stories, we can't wait for all 10. And we don't want to do multiple round trips to do one plus one plus eight. We need some sort of stream. And, you know, we used, it wasn't built into GraphQL.

It was built into the graph API, a batch API. And then we built a GraphQL batch API. And I think we're finally sort of reaching something that really is a nice declarative model. It's complex. The fact that we've been able to work on it with the community and that a lot of the work in the open source has been community driven, but using the sort of like work that we did within Facebook to try it out, I think we're going to come to a really nice conclusion.

I also think it's nice in that if you don't want AdStream and AdDefer, which in many cases you don't, like ban those directives, sure. Like that is entirely reasonable, but I think a lot of people are going to realize, hey, this is extremely valuable. I am, you know, ultimately I have a UI collection view or I have a list view. It's kind of nice to be able to bend exactly the first screen and then get the rest in order to improve performance. It's a common enough need. It's a complex enough problem that I think it's some real value that it can create. It comes up so much in our tooling requests, AdStream and AdDefer, that is like top of the list for years.

Yeah, no, I know. I will say one nice thing about the spec in general is that directives do let you extend it in a lot of ways. I mean, you guys are smiling, that was very forward thinking. That has allowed people to do a lot more than I'm sure you imagined at the beginning. Dylan do you want to tell everyone? This is I pushed back pretty strongly on adding directives because it was brand new in the spec and I was very much the person in the room being like, if we haven't tried it internally, are we really just going to guess and check in the spec? And a lot of things did not make it in based on the are we really going to guess and check? And directives, Nick and they are like, yes, yes, we are. This is really good. And they were absolutely... Yeah. I was like, Dan, this time Lee is like the Babe Ruth of distractions. Directives are great. He's calling it. I will stake my reputation on this. And rightly so. Well, hey, fantastic. Thank you all so much, everyone. I just got the one minute time notification that we're almost out of time. So, while I would honestly love to just keep talking because I've had so much fun just listening to all the wisdom that's been shared today. And I really want to dive deeper on a lot of those fantastic topics.

But maybe we can catch you guys in spatial chat or somewhere else and keep the conversation going. Because I mean, it's a pretty good one, and I'm sure the community would love to hear more. But I guess we're out of time. So that's it for the panel. And thank you all so much for all of your kind thoughts and kind wisdom.

I'm sure everyone that I'm seeing in the Q&A is really enjoying it. And yeah, if you'd like to hear more from the panelists, I'm sure you can find them on the GraphQL Galaxy website, and they have their contact information on there. And thank you all so much once again. See you around. Thank you.

That's a lot of people. Yep, yep, yep. Just the online nature of the course really helps with that. That's awesome, dude. Well, it's a pleasure to meet you all and it's a pleasure to talk to you all about GraphQL at scale.

So I guess without further ado, let's kick it off with a question. As I mentioned before, I think GraphQL is inherently a technology of scale. It was formulated at Facebook when scaling their data layer to accommodate multiple device form factors. So what aspects of GraphQL drew you to it when addressing those types of challenges of scale? Let's start with Dan. Yeah, I think the way in which it scales is interesting because it scaled differently over time in its evolutions at Facebook. The original problem of scale anticipated the need for multiple clients, even just scaling within a given client.

I think one of the original scaling factors that didn't necessarily draw us to GraphQL but drew us to Create was the ability for a client engineer to add features without versioning a server. Another aspect of GraphQL at scale is the technical aspect, where technology teams can scale and repeat work efficiently. GraphQL provides formalism for interactions at scale, offering solutions for common challenges like type safety, batching API calls, and more. This technical aspect of GraphQL's scalability is exciting and crucial for handling large-scale projects.

It obviously has proved very helpful in having multiple clients at once. Even just scaling within a given client, the ability for a client engineer to say, hey, I'm going to add this feature now. They don't have to version a server. They don't have to potentially make a server change if the data's already there because of the graph nature of it. I think that was probably one of the original scaling factors that I think didn't necessarily draw us to it, but drew us to Create.

I think one of the things that drew me to GraphQL, especially from scale aspect, was I think especially over the last few years from what I've seen in the ecosystem, is that there's two aspects to scale that are particularly important with GraphQL. The first is this technical aspect, which is that your technology team is scaling. There's a bunch of work that you're doing that is going to be repeated across all of these engineers whether they're consuming the API, building the API and whatnot. And GraphQL really creates a formalism for people to interact when they hit those levels of scale. You realize that, oh, well, we need to have something like fragments. But then it turns out, well, GraphQL has it. You need to have type safety and GraphQL has to expect.

So those technical aspects, or you realize that you're making multiple API calls, you should just be making a better batched API call. And GraphQL is in a way, this amazing batching technology. And so that aspect is exciting for sure. But I think there's also another interesting aspect of GraphQL at scale. And I see this especially in enterprise with what really appeals to people about GraphQL is not so much the technical awesomeness of what GraphQL lets you do, which is let's say performance and type safety. And to a degree maybe type safety, but also not the performance aspect of it and whatnot, but kind of more the metadata aspect of it, which is that this aspect of saying that we have this ability or we have this formal way or this way of specificifying our API and exchanging information about an API. And this is kind of more of a organizational human problem of scale rather than the technical aspect of scale, right? Which is saying that we should have really just done this right the first time, right? Like we should have had APIs, we should have documented them, we should have had like open API specs or whatever, right? It should have been better, but it's not. And for them, the appeal of GraphQL is, oh, finally, yes, this makes sense. We should have like this Explorer tool, like graphical. This makes a lot of sense. Why don't we have it? Why haven't we have it? We should have built-in documentation about at least the spec, if not the usage pattern of the API, at least the spec of the API should be documented and should be a part of the thing. And what I see from those kinds of users, right, is that they don't really care about GraphQL, the API method. They care more about GraphQL, just the metadata. They're like, you know what? At the end of the day, in fact, especially in enterprise, I would rather not consume a GraphQL API. I would rather consume a REST endpoint or a gRPC endpoint, something that we have the rest of our organizational tooling around, because we don't have so much tooling around GraphQL. And so we have so much tooling around so many other things is that they really kind of just fall in love with that metadata, that graph idea that ultimately all of your entities are related in some sort of a graph, right. And they really like that aspect, right. So I think the organizational scale aspect of GraphQL is very, very powerful, right, and it is also kind of very accessible to people. So that's kind of been two very interesting things to me about GraphQL at Skip. Yeah. That's super interesting. Oh, go ahead. Yeah. No, I'd like to build on that because I think I would have a unique perspective since I was the one who built the first prototype of the thing. And it was to Dan's point, it was not the fact that it was multi-device. It was kind of the realization of one, up until that point, my career at Facebook had been spent effectively being one of the people who really took it upon themselves to save our application monolith, which bleeds into another subject that we're going to get into later. But we had done a ton of work to build these abstraction layers and we had actually horizontally scaled our monolith across hundreds of engineers. And then it kind of started to see what would happen with mobile. And what was relatively clear is that you would have mobile engineers going up into the rest state, going up and building custom REST APIs. And it was fairly self-evident, maybe it wasn't self-evident, but I believe at the time that that would have been a disaster.

It would have been like the mobile engineers like Visigoths invading Rome and burning down the monolith we had saved. Um, so really the critical thing here is one, it was vertically integrated on top of an existing abstraction that was working. So the, the GraphQL layer on top of the internal Facebook abstraction was very thin. That's why I was able to build the prototype so quickly, not because I'm some amazing engineer, but because the, the, it had stacked on top of work that a whole team had done for like three years. And so that was one aspect. And then it was really about having a better relationship between the different types of engineers in the organization. Cause you could have server side engineers, publishing schema, and actually a pretty constrained way to mobile engineers that would then consume it. And that turned out to be a very help. Well, relatively healthy relationship that ended up scale. And I think dramatically better than the inevitable. Cause this would have been something where move fast, break things, Facebook culture would have just spawned, like I said, an invasion. And I think would have been really challenging to manage. Ironically enough, the dependency era, I think, in non-Facebook usage of GraphQL is inverted from in Facebook use of GraphQL where Facebook had a concept of, yes, these are the objects, call them ends, and Shrek can obviously talk more about that cause I was, his mom was a baby, but like it is, they existed and we'd had them for years and they were almost de facto. And GraphQL was like, okay, well we have this concept of the graph. The graph is great. These things have relationships. We understand how to fetch them. We understand how to connect the edge between them. If only we had this on mobile and listening to Tanmay and talking with folks on the outside, it's actually very often people are like, oh, GraphQL makes a lot of sense because I really want that representation. And you almost like, you realize how valuable that representation is because it's the representation that makes GraphQL feel most natural.

Well, the reason this is a representation that makes GraphQL feel most natural is because it's the representation we had. And like the, it's almost this inverted dependency. I think one of the things that really draws me to GraphQL is the idea that once you define what your graph is, you don't have to know exactly how people are going to use it for it to be really useful to them and the right thing for them. Like one of the things that originally drew Apollo to GraphQL was the idea that it could maybe be a technology to connect many different types of databases together. And it's just a really powerful thing to be able to define something that can be used abstractly by any different number of clients because the types of things people are building now are just way beyond what they were even 10 years ago. And you can't always predict how people are going to want to use your API or even keep up with it, so it's best to build flexibility from the get-go.

And you know, I have a question for you on that front. And in out in the wild of GraphQL, because I actually don't have too much visibility into it. Do you see people building GraphQL schemas that are specific to views? We used to call them view models. Or do you see more GraphQL schemas that are kind of like the core data model? That's a great question. I mean, I think people do it all sorts of ways. And earlier on, I think our recommendation was that you should design your schema for views, because that's going to be the most efficient thing for your apps. And I think when you are building an app, your schema should correlate to it, because that's the best thing for the application. But what we've been talking about lately, especially in Apollo, is you should use GraphQL to be the way that you define your data model for your company.

Instead of having your data models in lots of different microservices in different places across many different teams, dedicate a team to building the graph, have them define the data model, have every microservice team figure out how they fit into that and build into that, and then your data model can be... If you bring it up to the API layer, then it cleans a lot of things up, and it can just be directly what the clients use. And it makes client-side caching dramatically more straightforward. Sorry, go ahead. And also reuse. One of the things that was sort of amazing is after we defined the user object within Facebook, someone went out of field to user, and then the next person who came around was like, oh, shoot, I'm going to need to be able to show the user's cover photo. Oh, it's already there. Cool, I'm ready to go.

Exactly. Yeah, I think to take a stab at Nick's question, right? I've seen both I've seen people kind of really like structuring GraphQL around views. And then especially for people who are kind of going towards that event-driven microservices kind of style of things to kind of start thinking of like GraphQL as the Q in a CQRS kind of workflow, right? So that idea seems to have some weight and some momentum. And then I've also seen, of course, ideas where people like having GraphQL kind of described or using GraphQL around kind of the core data models. And I think it kind of boils down to the use cases that people have for GraphQL, right? And I think the client-centric use case, which is perhaps the original kind of the OG use case for GraphQL, right? Which is the better client API specifically for frontends, right? To communicate with backends. But then there's also kind of that platform-centric use case, right? Which is the use case of like, well, I mean, I don't know what 10,000 models I have and I want a better way of kind of understanding my models and what methods I have on my models or how to query my models or mutate them or whatever. And so there's both, but, you know, and I think like the trade-offs and like what people want out of it and what people want to optimize for kind of depends on, you know, what they're really solving for with GraphQL, right? Or what is that kind of problem that they really want to attack? Whether it's a back end for front end kind of problem that they have so many microservices and they want a better API or whether it's kind of like our API is just a mess and it's horrible for humans to browse, right?

Anne, how many types are in the Facebook GraphQL schema these days? I don't know, but it's got to be five digits. I would have to check. 25. It's not a real scheme until it crashes graphical, that's what we used to say. It was very, very apparent where things were quadratic and graphical earlier on. Exactly. I guess these days it's a matter of if you can load it with an Apollo Explorer if it's going to load or not. But I know, Danielle, you and your team are working with massive teams and massive graphs, and you're building a lot of tooling and infrastructure to really support all of those teams at scale. So I guess my question is, essentially what I'm hearing a lot from the panel so far is that it seems to be more of an organizational scalability type of challenge is how do I scale across more engineers? And how do I make the actual domain modeling of my graph kind of self-evident to adding more engineers to the team? So you mentioned that's something that you recommend at Apollo. And I'm just curious in terms of the tools and the infrastructure that you're working on there, is there anything that you offer within that tool set that can basically help with those types of things?

I know there are a lot of opinions out there on the right way to build a graph out of multiple sub graphs, and there are many options. But the one that we've been developing is really to come back to that idea that I said where your API and your graph should be your data model and everything should be feeding into it. Federation is really meant to help you do that because it helps you kind of define entities in certain places, extend them in other places, define how these partial schemas relate to each other. And that's the way that we see organizations being able to scale their graph, because you could imagine kind of one service per team in a big company where everyone is kind of federating into the overall picture. So what we're trying to do is build tools to help you use Federation and follow a model like that where you can really scale those things effectively.

I know that there are probably even on this panel a lot of opinions on what the right way to do that is, so I'm curious to hear from everyone else. Yeah, Tenmai, have you found any sort of ways to be more optimal and scalable? I think, again, it kind of boils down to the use case of what you're trying to federate, right? For example, again, if you have this situation where you are like, we genuinely have the situation where you have a bunch of mobile or front-end applications, and they've been querying 20 different microservices, and it turns out that all of these services do actually have a lot of interrelated data, right? And you want to create and operationalize a process of maintaining a central API that allows these front-end clients to consume that API, right? And so now you can have different approaches of building that out, right? And I think, again, like it depends on the organization.

I've been a little bit skeptical of automatically assembling that federated thing because it'll be interesting to see how that works. Because it kind of goes almost against the idea of microservices itself to say that, well, we wanted to make these things independent, but now we've made them dependent again. And they're kind of talking to each other like they should have been perhaps, but outside a usual channel of code. And so maybe GraphQL or a federation approach with GraphQL is a way to solve that problem again. But of course, there's more traditional ways of solving that problem, which is just to go back to everybody goes back to Monith or you maintain a GraphQL gateway in the center that some team maintains or whatever. So that's kind of one kind of problem where you have this.

So that's kind of one kind of problem where you have this. But I think this idea of saying that we should have... When you think about all of the APIs and all of the services in enterprise, not all companies in the world are Facebook, obviously, right? And they all have very different problems. In fact, traditional enterprise, it's very weird. It is not at all like a tech giant like Facebook, it's extremely different. There's a very, very large number of themes in LOBs like lines of businesses that are catering to very specific customer segments. And for them, the APIs that they're producing, the reason why microservices caught on in the first place was because for them, the APIs that they're producing, there's a very particular cognitive model around the API that they have. So now, if you suddenly say that I want all of the APIs in my enterprise, which is insane, because it's not possible for this massive like traditional Fortune 10, Fortune 100 companies to have the same. It is not the same API. They don't even have the same customer. I mean, it's insane across these different LOBs.

And so here, if you're introducing this idea of saying, well, let's all collaborate on a single graph, it's going to introduce more of an increased cognitive overload on people in consuming that API. They'd be like, no, no, no, no. Please, I don't understand anything that's happening. Please, take me back to the 10 end points that show me how to make a payment to a merchant and how to refund that payment from a merchant. That is all I want. I don't want to see this graph. So what problem you're trying to solve and what sections you're trying to maybe unify and why you're trying to unify them, again, is it driven from a technical performance back-end or front-end-type use case? Is it driven from a platform-centric use case of saying that, well, these 10 teams should have actually been one team and we should have actually had one coherent API. What is the use case? And that use case will guide that different kind of federation approach or whether you should even be using GraphQL or not. Those kinds of things will come out of that.

It's risky to say that there can be just one approach to GraphQL because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we used GraphQL for or built GraphQL for, and make an advanced decision. Tim, I actually love the way that you frame that up about decomposing technical and organizational determinations because I have very strong and polemical views on microservices. I think they're overused for sure. I think it actually ironically explains a lot of the popularity of GraphQL because a GraphQL schema is your subconscious telling you that you want your monolith back. And if you want to assemble a set of microservices into a single schema, which in microservices speak would be a single bounded context. If you're kind of into that language, domain different design. In my opinion, if that feels correct, then what you have is a distributed monolith, and it should have been a monolith in the first place. And I think there's going to be this really interesting counter reaction. And you see it in systems like out of Airbnb, there's a system called Viaduct. It's coming out.

At Twitter, there was a system called Strato where they're actually, they're moving compute back up into this federation layer. So that gives the client teams autonomy where somewhere they can push code where they don't have to talk to the microservice team. And I'm going to be really interested to see if more and more of the business logic naturally moves to that, you know, I think you referred to as a GraphQL gateway, maybe be like a smart gateway or something, or to like, call it like the application microservice, then everyone will be like, willing to accept it. You know, whatever it takes. So but in the case that you're talking about this separate lines of business, it's actually appropriate, I think that a separate service and a separate GraphQL schema, per line of business, because they are completely desegregated. bounded context or schema. So that's kind of where I'm at. It's a fascinating thing to see, because like, obviously, like not everyone who does microservices is like an idiot. You know, there's like a reason why people feel compelled to do it. They can no longer horizontally scale their org. So I totally get that. So I'm trying to be less flippant. I'm this. You have changed, Vic. It ultimately comes down to tradeoffs as well. And so, you know, the one that always comes to mind for me is this separation of concerns. Like separations of concerns is good when the concerns can actually be separated. When you're like, hey, these two things can operate independently.

And I think, you know, what I see if Facebook sort of legendarily is a monolith, kind of like News Feed has its own backend, Timeline has its own backend search has its own backend, like, you know, it is a monolith in terms of its business logic is monolithic. But in terms of some of, you know, if you're trying to store stateful logic for News Feed, yes, that's going to be in a service. Well, why is the business logic in a monolith? Because of feed, because fundamentally, you cannot separate the concerns of the, you know, Facebook application, the app that you open, because you're in a feed, and you see a story about, you know, Nick, attending, you know, this event, and you see a photo that I posted. And you see, you know, the fact that, you know, Danielle checked in someplace and all of these sort of things that could presumably be independent services, they do inherently, like you cannot separate those concerns. And I exactly sort of shared an excitement, which is if you've got 10 microservices, and they all have the same API, it goes, of course, these have the same API's. Well, how did you actually separate those concerns there? If those 10 things fundamentally need to relate if the interaction between those 10 services, you know, can't be decoupled, we can't be decoupled, and yet we chose to decouple them.

And on the other hand, if you can decouple them, it's like these two graphs are independent. I actually have no idea what value you would get by putting them into the same GraphQL API that feels sort of like a false dependency. There is a little more, I think sometimes reality ends up being a little, like, it's a little harder to say upfront, are we going to be dependent on each other, or are we never going to talk to each other, right? It's hard to say, right? Like, what we've seen from people is where we've seen like separate, like kind of LLBs, right, or lines of business, adopt that, adopt kind of GraphQL, get very productive with it. But then suddenly this team realizes, oh, man, there is some data that that team has, which if I had, it'd be amazing, right? And now suddenly they're like, oh, my goodness, what do we do, right? Like, how do we set this up together? We have to build some things. I wish we didn't have to build this, right? So there's a little bit of like the natural dirtiness of life that gets in, where things are not clear and people don't know how to do things that make it a little bit harder to think about what should be what upfront, especially in teams which especially in teams where the organizational structure promoted autonomy rather than collaboration, right? If you think about, with microservices, what's happening is you're having organizations that promote autonomy.

With monoliths, quote-unquote, you have organizations that are promoting collaboration, right? It's two sides of the, it's the same thing, but a little bit different, right? So, I think, and I think that kind of complicates that it makes it a little bit harder for people to choose upfront, right? So there's some interesting things there. To Nick's point, though, one thing I'd like to add is, like our crazy idea hypothesis is that there are some kinds of business logic that you can actually absorb into that GraphQL layer. And it's repetitive that maybe you don't have to repeat again and again, right? And, for us, our gut feeling is that authorization when related to data and caching are two infrastructural almost concerns, but still concerns that every single developer has to deal with that could be brought into a common layer, right? So that's the lens that we're taking with it. It's not necessarily a GraphQL lens, but it's a lens of, like, this is repeat work that we're doing across a bunch of people that maybe we can bring somewhere, right? Which is a type of business logic that can be made common across a large number of people, right?

But so it would be interesting to kind of see how that evolves, of course. I'd like to hear Danielle's thoughts on this because I feel like as an Apollo employee you're dealing with the kind of aggregating microservices problem a lot. Yeah, I think where the microservice and federation model shines is, like, close to what Tanmay said, when you have different teams or lines of business that want to have autonomy yet have things that relate to each other and still want to be able to bring those things together. So I mean, even inside Apollo, we build a big SaaS tool, we use federation, and we have this debate all the time. Like, we have some microservices, but we don't have, you know, four teams working on them, we have two, and we're like, why do why did we split these things up? In some ways, we're creating more overhead for ourselves than but in other cases, you know, when you have another team that's entirely independent of you, that's running services that don't relate to you, you're not on call for them, you don't want to be responsible for them, yet you're still in abstracting that it's a good idea for those two services to go into the same graph.

Then that's for something like federation, I think, shines and kind of enables you to contribute to the same overall thing while letting teams remain autonomous and keep their own life cycles. So yeah, I mean, it's all like it depends, right? It depends on what you're trying to do, what's right for you. Higher organization is structured. It's yeah, it's the messiness of humans. Awesome. Wichita. That's fantastic and, yeah, I think we can we can talk a lot more on this topic, but in the interest of the wider audience that we have, let's move on to a slightly different one, but maybe let's get back to this one before we end things off. So in terms of the GraphQL spec, I mean, we're all here today because of GraphQL and we're all here today because of the GraphQL grammar and the GraphQL spec. And since the time I've been using GraphQL, it's remained mostly unchanged in terms of the core grammar.

The core grammar is was fundamentally what it was. But of course, as we keep applying more paradigms to that same grammar, we're starting to see a bit of an evolution in terms of the grammar, in terms of the spec, and in terms of how GraphQL is being used. So I guess my question is that with more paradigms being added, like essentially, what are you most excited to see in terms of GraphQL? Like, which paradigms are you most excited about? And in which ways are you most excited about seeing the GraphQL spec being applied to those paradigms? And I guess we can start with Tami.

I had, I was, I had a, I have a, I have a non-answer controversial answer to this question, which is that, I feel like what we can, I feel like what I would really like is a GraphQL Lite, which is a reduction of the GraphQL spec. For, for some of those kinds of platform-centric use cases that I talked about, where what I would like to do is kind of like, say, for example, get get rid of like, let's say, interfaces and unions, right. And kind of like simplify that a little more so that essentially the purpose would be so that what I would like to achieve is almost a kind of a bijection or a mapping between any GraphQL query to a rest API.

And I feel like that can't happen right now, because GraphQL has more specific things. It's harder to achieve right now. It's a little more complicated. But simplifying that so that we can have like a mapping to a rest API model, I feel like that would be extremely useful to a lot of people who are looking at de-risking their adoption of GraphQL, because then what happens is that they have a lighter way to kind of enter GraphQL with a subset of the spec, but in a way that the rest of their existing tooling doesn't go to the dogs, right? So that existing tooling can start to emerge and work right, because it's just a tremendous amount of like inertia that the existing API tooling that people have and the tools that they're using and how they've gotten used to it.

Everything from OAuth to API management to error handling. Error handling is so confusing in GraphQL because you get partial errors, right? This is a problem that people just, yeah. So sorry... No, no, no, no. It's not just, not it's not just a forever skeleton in our closet. Yeah. It's the 200 response problem, right? It's like everybody is used to, there's so many vendor tools today where if you just plug that into your API, you kind of get like a tool that says this API is not working because the status code is 4xx or 5xx or whatever, right? But now with GraphQL you can't do that. You have to kind of inspect the response. So now your vendor tool needs higher privileges to inspect your response. Nobody's prepared for this because it violates all of their compliance, right? They're like, what? No, there's no way this monitoring tool is getting access to my response body. And so what they want is the return to a simpler world where they're like, well, no, we had already done this, this problem was solved. So maybe I'm not sure if this moment is even feasible or make sense, but it's just a random idea, right? It's like a random, like a thought process of like what would happen if GraphQL was maybe a little bit simpler on some things or maybe simpler is not the right word, right? That allowed kind of that intercompat or incremental evolution to happen from where people's APIs are today. So, that's a- To be fair, I think a lot of the problems you're describing can be solved with software, software layers on top of GraphQL. So like, for, you know, like, for example, the compliancy you make makes total sense and the, so like, for example, if I was, you know, dealing with that problem, you know, I would try to distinguish errors that are like non-ideal states in the application, from hard errors and then have a software layer that translates the hard errors to a- Exactly. To a hundred, right? Exactly. I don't think you need to change the spec to solve that actually. A hundred percent. You know, for example, you can also choose server-side just simply not to support or to link or assert against using certain features, such like the bijection that you're talking about. So- Correct, correct. You know, I think you, we, you know, we can solve that in the software- Completely agreed. Yeah, yeah. And I, I, I, the reason why I, I used, I said spec is because I think those tools need to get a little bit standardized, right? Because what people don't want to do is they're like, wait, no, I don't want to build this software that will do this for me, right? Like I don't want another piece of software to maintain, I, I just want this to be done, right? So- You want to, you want to rescue our spec, that's what I'm saying. Yeah, I want to rescue, exactly, that's the- I would love to see continued work in errors. I mean, Nick and I were sort of laughing about it. I have a very distinct memory of a conversation where it was just like, what do we do with errors in the spec? And it's like, well, the way that we handle errors is bad. So we can put that in, and that's a bad idea. Or we could guess and try and put something else in there, or we could leave it relatively underspecified. And like, I think it is, it is a really hard problem. And if, you know- Understand. Evolution in the community a better idea.

Like, I don't like how errors are handled right now. I hope we come up with something better. And the community is innovative. Like, I actually think that Saatchi's pattern of- Oh yeah, the union error pattern. It's just like, it's just like, what's that about? And I was like, what? Ugh, what do we think of that? But thank God we had the generalized abstractions to support that. That time I once get rid of- No, I'm just kidding. Um, one thing that I'm really excited about is AdStream and AdDefer. Where I feel like those sorts of, you know, streaming responses is something that, you know, I think it was probably 2013 when we realized, okay, yeah, if we're vending 10 feed stories, we can't wait for all 10 and we don't wanna do multiple round trips to do one plus one plus eight. We need some sort of stream. And, you know, we used, it wasn't even built into GraphQL. It was built into the graph API, a batch API, and then we built a GraphQL batch API. And I think we're finally sort of, you know, reaching something that really is a nice declarative model that's complex. The fact that we've been able to work on it with the community and that a lot of the work in the open source has been community driven. You know, but using the sort of like work that we did within Facebook to try it out, I think we're gonna come to a really nice conclusion. I also think it's nice in that if you don't want AdStream and AdDefer, which in many cases you don't, like ban those directives, sure. Like that is entirely reasonable, but I think a lot of people are going to realize, hey, this is extremely valuable. I am, you know, ultimately I have a UI collection view or I have a list view. It's kind of nice to be able to vend exactly the first screen and then get the rest in order to improve performance. It's a common enough need. It's a complex enough problem that I think is some real value that it can create. It comes up so much in our tooling requests at stream and AdDefer that is like top of the list for years. But one thing is like... Yeah, I know, I know. Seriously, I will say one nice thing about the spec in general is that directives do let you extend it in a lot of ways. Like that, I mean, you guys are smiling. I just, that was very forward thinking that has allowed people to do a lot more than I'm sure you'd imagined at the beginning. Dan, do you want to tell everyone? No, I pushed back pretty strongly on adding directives because it was brand new in the spec and I was very much the person in the room being like, if we haven't tried it internally, are we really just going to guess and check in the spec? And a lot of things did not make it in based on the, are we really going to guess and check? And directives, Nick and Lee are like, yes, yes, we are. This is really good and they were absolutely- Yeah, I was like, Dan, this time, Lee is like the Babe Ruth of distractions. Directives are great, he's calling it. I'll stake my reputation on this.

And rightly so. Well, hey, fantastic. Thank you all so much, everyone. I just got the one minute time notification that we're almost out of time. So while I would honestly love to just keep talking because I've had so much fun just listening to all the wisdom that's been shared today and I really want to dive deeper on a lot of those fantastic topics. But maybe we can catch you guys in spatial chat or somewhere else and keep the conversation going because it's a pretty good one and I'm sure the community would love to hear more.

But I guess we're out of time so that that's it for the panel. And thank you all so much for all of your kind thoughts and kind wisdom. I'm sure everyone that I'm seeing in the Q&A is really enjoying it. And yeah, if you'd like to hear more from the panelists, I'm sure you can find them on the GraphQL Galaxy website and they have their contact information on there and thank you all so much once again.

See you around. Thank you. Thanks for having us.