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 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 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 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. Can I 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 area of interest and workspan 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, 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. 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 the scale of your data? 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 necessarily multiple clients at the same time. It was actually the scaling of the data layers that change over time where we knew that the new suit 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, it 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 is already there because of the graph nature of it. So 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 scale aspect, 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 it turns out, well, GraphQL has it, right? You need to have type safety and GraphQL has it as spec, right? So those kind of technical aspects, so 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, right? 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 kind of what is appealing to people 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 okay, 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 specifying our API and exchanging information about our API. And this is kind of more of an 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's 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. 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 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. 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, well, relatively healthy relationship that ended up scale. And I think dramatically better than the inevitable. Because this would have been the type of thing where like move fast, break things, Facebook culture would have just spawned, like I said, like 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 usage of GraphQL, where Facebook had a concept of like, yes, these are the objects, called them Ents. Shrak can obviously talk more about that because I was his mom's baby. But 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. 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. 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 in, in out in the wild of GraphQL, cause 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 team to 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 with the clients use. Yeah. And it makes client side caching dramatically more straightforward. And also reuse. 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 would add a 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 the user's cover photo. Oh, it's already there. Cool. I'm ready to go. Exactly. Yeah. I think from 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 event-driven microservices kind of style of things to kind of start thinking of like GraphQL as the queue 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 describe 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 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 both. But, yeah. 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. And 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 early on. Yeah. 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 mean, like I know, Danielle, 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 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 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 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? Yeah, I think, again, it kind of boils down to the use case of what you're trying to federate, right? Like, for example, again, if you have this situation where you're like, 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, 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 go back to everybody goes back to Monith, or you maintain a GraphQL gateway in the center that some team maintains or whatever, right? 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, right? Not all companies in the world are Facebook, obviously, right? And they all have very different problems. In fact, traditional enterprise has, 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, 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, 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, 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, build GraphQL for and make advanced guess. Yeah, 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. And 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 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 that's 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 of 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, there's separate lines of business, it's actually appropriate, I think, to have a separate service and a separate GraphQL schema per line of business, because they are completely disaggregated, bounded contexts or schema. So that's kind of where I'm at at the moment. It's a fascinating thing to see, because obviously, not everyone who does microservices is like 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, Vic. It ultimately comes down to trade-offs as well. And the one that always comes to mind for me is the 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 is 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 it, 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 open, 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 in event 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, 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, but 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. 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? It's hard to say. What we've seen from people is where we've seen like separate, like kind of LOBs, 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? How do we set this up together? We have to build some things. I wish we didn't have to build this. 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 with the organizational structure promoted autonomy rather than collaboration. 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. It's two sides of the, it's the same thing, but a little bit different. So I think, and I think that kind of complicates that it makes a little bit harder for people to choose upfront. So there's some interesting things there. To Nick's point, the one thing I'd like to add is like our crazy idea or 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. 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. So that's kind of the lens that we're taking with it. 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. 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. Cause I feel like as a Apollo employer, you're dealing with them kind of, you know, 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 things, but 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 not like it depends, right? It depends on what you're trying to do, what's right for you, how your organization is structured. It's, yeah, it's the messiness of humans. Awesome. That's fantastic. And yeah, I think we can talk a lot more on this topic, but in the interest of the, in 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? I guess we can start with Tamay. 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 light, 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, 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, a kind of a bijection or a mapping between any GraphQL query to a REST API. And, and I feel like that, that can't happen right now because GraphQL has more specific things. It's harder to, harder to achieve right now. It's a little more complicated, but, 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, that existing tooling can start to emerge and work, right? 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, or 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. So. Sorry. No, no, no, no, it's not just, not, it's not just a. Forever skeleton in our closet. Yeah, just, 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 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, 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, so, so maybe like, I'm not sure if this moment is even feasible or makes 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, that allowed kind of that intercompat or incremental evolution to happen from where people's APIs are today. So, so, so that's a absolute non-answer 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, for, you know, like, for example, the, the compliance thing you make makes total sense. And the, so 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 200, right? Exactly. I don't think you need to change the spec to, to solve that actually. A hundred percent. You know, for example, you can also choose server-side just simply not to support or to lint or assert against using certain features, such as the bijection that you're talking about. So, you know, you know, I think you, we, you know, we can solve that in the software. Completely agreed. Yeah. Yeah. And I, I, I, I, I, the reason why I, 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 just want this to be done. Right. So you want to rescue our spec. 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 at 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 under specified. 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 Satchi's pattern. Oh yeah. The union era pattern. It's just like, what's that? And I was like, why, why don't 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. One thing that I'm really excited about is a ad streaming out defer where I feel like those sorts of, you know, streaming responses is something that, you know, we, I think it was probably 2013. 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 even built into graph QL was built into the graph API, a batch API. And then we built a graph QL batch API. And I think we're finally sort of, you know, 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, you know, 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 to have streaming out defer, which in many cases you don't like, and 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, 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 as streaming out defer that is like top of the list for years. But when they get there, 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 like that. I mean, you're, 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 imagined at the beginning. Do you want to tell everyone? No, this is a, I push 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 were like, yes, yes, we are. This is really good. And they were absolutely. Yeah. I was like, Lee, I was like, Dan, this time Lee is like the Babe Ruth of distractions. Directives are great. He's calling it. I'll, 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, but maybe we can catch you guys in a, in, in spatial chat or somewhere else and keep the conversation going. Cause I mean, it's, it's, it's, 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, for all of your kind thoughts and kind wisdom. I'm sure everyone that I'm seeing in the Q and a is, is really enjoying it. And yeah, if you'd like to hear more from, from, 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.