Let me introduce those distinguished guests, starting with Benji from Grafel. Benji is a community-funded open source project and Benji is the main maintainer. He loves doing GraphQL, truly loves doing GraphQL and helping the community. I'm really excited to have Benji here. We have Danielle Mann from Apollo. She's a senior director of engineering at Apollo. Danielle has been working on making GraphQL easier and more delightful to use for the last six and a half years. It's amazing to have someone with so much experience here. And Tim Shuchanek, I'm sorry if I'm butchering your name, from Stele. He's the co-founder and CEO of Stele. Tim was the first employee at the first GraphQL backend as a service that we all remember six and a half years ago and is now working on making it easy to run GraphQL APIs in production at Stele. And Frederick Dior from Graphbase. He's the founder and the CEO of Graphbase. They make it super easy to deploy serverless GraphQL backends. So thanks everyone for joining me and for this panel. And this panel has a very big title, what is the future of GraphQL? And I think all of us probably have a lot of different perspectives from all of the many different areas that the people here are part of. So maybe we can start with Benji. Just in a very, let's call it general terms, how do you see the current trends in GraphQL? Like where do we, when we started and where we are today and some of the exciting things you are seeing out there. Thanks Yuri. GraphQL, I think, has grown quite impressively. It sort of rocketed out since its launch in 2015. And it's really interesting to see people, I think the base GraphQL like addressed a lot of people's problems and we're now starting to see the edge cases of those where certain patterns aren't fully covered and we're then looking to deal with those. So in my work with the working group, we've been receiving the requests and the ideas of various people as to how to advance GraphQL, how to make it serve all these different needs. And I think Lee spoke about earlier the new deference stream, which is one of the exciting things that is being added to GraphQL currently, which is great. But there is also a huge number of other proposals that are all being worked on as ways to advance GraphQL. And some of them may never see the actual final release into the spec. Some of them may spawn better ideas that solve the problems in better ways. But what I love to see is people really getting involved and working together to find these solutions to these common problems. And rather than thinking, how can I solve this for my one business, thinking, how can I solve this for everyone that uses GraphQL so that this rising tide can lift all boats, as it were. Yeah. And I see, I'm really interested also in Daniel's perspective, because I know that in Apollo, you're basically probably seeing so much of user stories of how many different types of companies are using GraphQL, both on the front end as consumers and back end. How do you approach this question? Yeah, I think as the last six and a half years have progressed, we've really seen GraphQL kind of move from being a super early technology that needed just a lot of basic tools to help you use it in general, to now we're kind of entering more of the early majority phase where a lot of people are looking for more sophisticated things out of GraphQL and starting to build off of GraphQL to do things like defer or to do things like live queries, which is something that we talk about at Apollo. So I'm really, I mean, even just for the use case of defer, I'm really excited about how we're starting to get to being able to roll that out because with defer, it doesn't just make your GraphQL queries more performant. I mean, well, it does, but like, it's not just about making your queries more performant. It actually, once you've moved that kind of consideration of how the data will load in chunks back to the GraphQL query layer and out of your React render layer, you can make your React apps a lot simpler. You're going to architect components in a different way because you're no longer going to need to break up front end pages component by component just because you need to load data progressively. So even just within the last month, I've started to play around with defer and some of my own apps because we had an early implementation at Apollo and I was realizing some of those things and I was having this moment of like, oh my gosh, this is going to change how people build their front end components. This is wild. Like I'm excited about GraphQL all over again. And so I'm really excited that we're like entering this phase of like defer, live queries, like all these other, like caching, like what Tim is doing, all these other amazing things on top of GraphQL now that we've gotten past the basics of just making GraphQL available to the masses. What do you think would be like the biggest conceptual thing that people can now do with defer, like the biggest aha moment for you when you started playing with this? So my aha moment, I was, I mean, we have a big front end app at Apollo called Studio and we, every time we load a list of things, like have one query for the list and then one query for every component of the list so that the list can show up. But then like a metadata on that list can load more progressively. And so when you just load one page, it's maybe like a hundred queries, which is just so many. And so I had this aha moment of like, oh my gosh, with defer, this no longer needs to be organized this way. This can all just be one query. It's going to be so much better for the front end developers who no longer have to break this component up on these boundaries. It's going to be so much better for the server that no longer has to deal with mega load. So even just that, it was such a simple moment, but I was like, the potential here is so high. So exciting. Yeah, I agree. And you also mentioned like queries and I know a bit that like GraphVis has started playing a bit with those things. Maybe you can take the, like the question from your perspective, Frederick, like what are the most exciting upcoming things for you? Absolutely. I mean, I think just to double click on GraphQL where we are, I think the fact that it's becoming a bit boring is a good thing, right? It's no longer being hotly debated. It's here and it's here to stay. So I'm pretty excited about that. Now we're refining and adding things to make it easy for anyone to adopt and to generalize common patterns. So I like that. But yeah, on our end, like we're also looking at defer and stream and we actually have experimental support for live queries already. And most people I think know of GraphQL subscriptions, but I don't know, not everyone knows about live queries. So that's another example of just making real time really easy. And that's obviously something that we care deeply about because we want to make GraphQL servers easier. I think the kind of common knowledge, at least in my experience, has been like building GraphQL servers is a bit hard and fragmented. So that's something we're excited to make better. Yeah. I mean, that leads me to the next question. Like I think, I agree with you that like we got to the, it's funny how you said it, like we got to the boring phase where we know more or less what is GraphQL, like we have these things, but now there are some challenges. And I think probably someone who's like, been into this problem for so many years, this team, like, because of GraphQL, right? Where you're one of the first that actually looked at like how to make it as easy as possible, as simple as possible. And you've been through a lot of waves and like iterations over these six and a half years. Like where do you see the, I guess, let's say the current challenges, like of where we are in and what would be the easiest wings moving forward for the community? Yeah. So I think that that's actually a good question. And I definitely have thoughts on that. I think that there are two, let's say big areas I see education and tooling. And I would even say that education is probably more important right now because we see that there are a lot of misunderstandings. Every second day there's a discussion these days. It's a bad tool or whatever. And you see that there's just a base misunderstanding. I think it starts with, we see that GraphQL is very valuable in teams and companies. You have GraphQL as a collaboration tool that brings people to the table at the same table and they can talk about something. And now it's kind of a forcing function, has a lot of advantages there. And I think that's still something that many companies don't understand. And for that, you first need to understand your own, you first need to be self introspective in the company, understand your own issues. Let's say there are 10 different authorization solutions out there. What is the issue? It's maybe a governance issue. Okay. Once you identify it, now you can see if there may be a tool that can help us. And I think that's a few steps down the road. And it's a lot of education that needs to happen to really get the benefits. Also relay style GraphQL is also still quite different than what is used in, let's say, a lot of starter projects and people have this barrier to relay, although there are a lot of advantages in it. And I think there's a lot of education needed. On the tooling side, I think everyone here is working on something to make it easier and move GraphQL forward. And it's a huge, it's something on all of us, right? Not just one person or company can move that forward. And I think as long as we all move forward and that's like the spec is combining all of this is holding us together. I think that's amazing. Yeah, I think I agree. I think education is very important. And also, but I always keep wondering if we can. Because education also sometimes means people need to know more things or to, some things are just make sense when you getting into more complex applications. But I always ask myself, can we build better tools for the beginner, where you start easy, you get what you want, and then you just gradually get into where you want without, I don't know, jumping between things or I wonder if any of you have, I don't know who wants to take it like, but how do you imagine us solving this path in the future? Like, let's say I'm a beginner, I'm starting, I know it's a beginner, but I, I'm a developer who's starting a new app. And I want to start easy and fast, but then I want to make sure that I'm not, you know, cornering myself with things. Do you think we're there right now? Do you think there's things needs to be changed? Do you have concrete ideas of things like that? And maybe, maybe Daniela can take it. Yeah, I actually, well, I kind of wanted to ask the rest of the panelists, because my take on that is we have so much material on helping complete newcomers to GraphQL, GraphQL get started with GraphQL. Like we have starter kits, we have a lot of easy ramps, but I feel like what we're still in the process of building in this community is easy answers, easy standards for the more complicated and advanced questions. Like on the Apollo side, we have a lot of tutorials, we have our Odyssey learning courses, we have like a lot of docs with getting started guides for, yes, how do you write a resolver? Yes. Like how do you write a query in your client app? But once you start getting to more advanced complicated topics, a lot of that is still very much within specific companies, specific technical teams. And I feel like we haven't standardized those answers. And Benji, I was actually kind of curious from your perspective, how you think about that, because right before we hopped on the panel, Benji and I were talking about his new project around a different way to write GraphQL resolvers. I'm curious how you think about teaching people how to do GraphQL while on the backend. Yeah, it's a great question. And I think one of the key things to keep in mind with GraphQL is it was always built to solve client problems. It was always built to solve the problems of the front end. And just like you were describing earlier, Danielle, with defer and your breakthrough moment, it helps, it's always focused on those, making those front ends easier. But like Frederick said before, it's not always the best at making the back ends easier. And there are so many different approaches to building GraphQL schemas. I mean, even choosing what programming language you're going to build them in is one first question. And even from there, you've got various different questions, depending on what libraries you have available. Do you want to go schema first? Do you want to go code first? Do you want to go database first? Do you want auto generation? Do you want to do it manually? There's even fundamental questions about the design of your schema, like should we be using cursor connections or do you just want simple lists? And I think a lot of people always want to start the simple way. But one of the things that GraphQL tries to help you accomplish is making your schema backwards compatible. You want to always be able to add stuff to your schema without breaking previous applications. And so there's quite a few patterns in GraphQL that initially seem over complicated. So connections, for example, the mutation pattern where you have like an input object and a payload object, various things like that, that people might initially think, I don't need all this stuff. I just need to, if I'm going to create a post, I just need to return the post. But then later when they realize, oh, actually, when I create the post, I also want to know, maybe it cost me some money to create the post. How many credits do I have left after this? If you had done it with a payload, then there would be this space afterwards. So it's always about thinking in terms of the future of your schema. And I think that is maybe where education on the front end of how to consume GraphQL is relatively straightforward because you've already got a schema. Someone's already designed that for you. Now, all you need to know is how do I query it? How do I integrate this with React or Vue or Angular, whatever it is you're working with? Whereas on the backend, it's not just a case of learning what GraphQL can do, but it's also learning what it should do and how that integrates with your business domain. And I think that's quite a hard challenge to solve in general. You asked about my project, which is called Graphast. And one of the things that I see a lot of people saying about in GraphQL is, you know, the N plus one problem and the caching problem and various things like this. What Graphast sets out to do is to solve these problems out of the box by actually getting rid of the resolver-based execution model that we have in GraphQL currently and replacing it with a completely alternative execution model. Now, this isn't to say that resolvers are concretely bad or anything like that. It's more to say resolvers set the baseline of here is what it should look like, here's what it should be perceived as to the user as if it did this. But on the backend, if we do something a bit more advanced, but not necessarily with more complicated code, we can achieve better outcomes and we can avoid, we can sidestep a whole number of these problems, the N plus one problem and much more just out of the box. What are other interesting ideas that makes it easier to build GraphQL servers on the backend? Do you see other interesting ideas, like, by the way, I saw a glimpse of Graphfast is very exciting. But I know that both Tim and Frederick have also interesting ideas there. Frederick, maybe do you want to also give an idea of how you see this idea that writing GraphQL on the backend is hard? I was muted, sorry. I was going to continue on what Benji said there in terms of, there's just a lot of decision making you have to go through before you actually see the API on a URL in production somewhere. And I think that's the problem we want to solve. And also we want to have really low barrier of entry, starting with your terminal and local dev, right? I don't want you to have to install Docker or Java or set up complicated YAML files or anything like that. I want to get you from the idea to the URL and that's the kind of benchmark we need to look for. It should be minutes, not like a day or two. So I think that's an interesting proposal. And I think, we're starting with the simplest thing in my mind, which is one file and it's schema first. But of course, I see the benefits of having code first when you reach certain scale. So we will definitely allow that. But what is the simplest way to get a front end developer to deploy a GraphQL API? That's really what we're looking for now. And over time, making it more interesting for full stack and backend devs to deploy GraphQL servers. And I think if I would put an analogy where we are now, it feels like where React was before there was a framework and another framework. So a framework for React, I feel we need more frameworks for GraphQL that make it really easy to adopt. And I'm not going to use any names, but I think you know the names and they're really successful and I like them. But now we're also seeing that go into another phase. But I think that's what I'm looking forward to, being the coming generation of frameworks. I guess, so it's interesting, your idea of frameworks, because I mean, we are talking here about backend and frontend, but also in GraphQL, it's kind of like made the boundaries a bit more weird. Like there's a lot of frontend developers that started writing schemas and resolvers and backend code, and suddenly the boundaries became less expressive. Like, who are we talking about now that we're when we're writing the backend? And I think one of the things that I liked about GraphQL is that for me personally, even it just opened the doors to learn about all these concerns that Benji was mentioning. Like before that I was like, I didn't even think about it, but with GraphQL, I kind of like gradually got into that, like I started with just writing GraphQL and then I had to solve this and I had to solve that and I got tackled into this and got tackled into that. So I guess there's also a question of, maybe it's less backend and frontend, but more, let's call it data source implementation, GraphQL APIs, frontend consuming, like there's many different boundaries there and the roles are also like different, I guess. I think also for me, I mean, I wanted to, there's the complexity on the backend that we mentioned. I think there's for me also this question on the frontend. I think for us or for the people here looking at the GraphQL query, it seems like the most simple and beautiful thing and just like a very nice abstraction. But I think what we see from the community in the last few months, at least, is that maybe for some people, it's not the most, it's not the best. We see more and more people that are, let's call it frontend developers or product developers that are telling us things like, maybe GraphQL is not easy enough for us. Maybe we want something simpler for some cases, like there's the, let's call it the elephant in the room, but PRPC, for example, or all kinds of alternatives. And I wonder, I have a very particular opinion about it, but I wonder if any of you wants to, what is your opinion of this kind of trend or this kind of, let's call it the sentiment right now, where people are saying that GraphQL on the frontend is harder than it should be? Maybe you can pick. I can go next. Yeah. I mean, I have been building the Prisma client, which is basically a type safe access to a database like it's not an ORM, it's a query builder. And actually the implementation under the hood, it looks quite similar to GraphQL. So it's possible to build something that is nice and easy to consume from TypeScript. You have a little bit of a syntax overhead always. I think the minimum, absolute minimum, beautiful syntax is still GraphQL. You probably can't reduce it. However, something I think that is beautiful in TRPC is that you have a global type inference coming without me having to provide the output object type. I can directly just use it in the frontend and whatever I'm returning, I'm done with it. And I mean, in a sense, that's the trade-off you make with GraphQL that you also have with REST. Recently talked to someone who was using REST in a company that just grew from 40 to 400 people. And they have the mantra, if we need an endpoint, we just build it. And you can scale quite far with that. And I think what's nice about it is that every endpoint, REST endpoint is kind of an isolated container almost. That thing only does what it does and you can control it. Of course, it's not really scalable. And there's a reason that many big companies came to the same conclusion that the direction of GraphQL, to Falco and so on, all moved in that direction. So I think at a certain scale, it makes sense. I also think that there's for sure a point to make on making some default selections, maybe building that into the client. That's a design decision we made back in the days with Prisma Client. And we say scalars are, for example, the default selection. In many cases, if you say user find many and the server and the database are next to each other, it's fine. And I think that's also something you see in many GraphQL server implementations. Probably not something that will ever happen in GraphAs, that's what it's for, to have really this super optimized query plan. But yeah, I think maybe looking into default selections, that could be a direction as well. And I'm personally a big fan of TypeScript bindings. And also I want to mention that, I mean, Flow still exists, right? I mean, it's all about TypeScript these days, right? And Flow exists. And I mean, not too long ago, they added more GraphQL language support directly into the language and that might also be an opportunity with TypeScript. I mean, GraphQL by now is not just a little niche language anymore. We could also see is there something we can do. That's very interesting. I think, yeah, there's always the question like when, also on the front end and also on the back end, but in the front end of when should you start introducing GraphQL? And I think, yeah, like you said, the TypeScript integration today, it's I think something that many people are mentioning is painful. Like they look at the code and stuff as something that is painful for them and they want like inference, but personally, like we tried all kinds of things currently. There's some lacking features in TypeScript actually that makes it a bit harder, but might be interesting to tackle it as a community maybe to make it so you won't need a coaching step on the front end. Also I guess some of you mentioned frameworks and I wonder if we're looking at the use case of let's say specifically TypeScript on the back end and on the front end, like could we simplify some of these steps if we assume all kinds of, take all kinds of assumptions, right? GraphQL is very strong when we have a complete separation and that gives us complete freedom between how we build the back end and how we build the front end and if there's any tools, anything. But what if we do take these assumptions? What if we look at the specific audience and say, you know what, like maybe we, let's say you assume using TypeScript full stack, what would that experience like that look like? I wonder if any of you have thought about this, even if you are, I don't know, have any thoughts on that. Danielle? Yeah, I could take that one or at least a first shot at that one. I feel like if you use, there are so many tools for GraphQL, if you use them all together, you can get an experience that's kind of similar to TRPC. So that's one of the things that I love about GraphQL, but you do need to know, oh, I need to install this extension, I need to configure TypeScript code gen that way. And like even code gen, I mean, as we build new features like defer, we're going to need to move that support over and code gen and it's a lot of steps. So I would love to see us find ways to move the underlying technologies forward. So maybe we can combine and simplify and that stuff can get easier over time. Uru, to your question about framings, that's a really interesting one because Apollo's kind of history before we were doing Apollo was with the Meteor framework, which was a very opinionated stack. And I feel like a lot of our opinions from Apollo have evolved out of wanting to provide more modularization. Meteor was like complete batteries included full... Uru's laughing because he also worked on Meteor with us, but like full client to server integration and it was very beautiful. And also the feedback we got at the time is a bit ahead of our time and people wanted more database options and more server options. And I feel like that's always going to remain true. People are going to want to be able to do code for schemas, they're going to want to be able to do schema for schemas, they're going to want to choose the language that's right for them because they have a bunch of Java developers or a bunch of JavaScript developers or a bunch of Python developers on their team. So at least our current take at Apollo is embrace that, like embrace the beauty of all the different servers and try to put as much as we can in our router. Obviously that means people need to run our router, but that's kind of where we've tried to create that batteries included experience between our router and our client, but then provide the flexibility for the kind of behind the router. People can implement GraphQL however they want. Oh, I think Frederik, you're muted. Oh, am I? Yeah, now we can hear you. Okay. Yeah, now we can hear. I mean, I think TRPC is a really interesting project, but I think it's a novel idea to say that you're going to stay to a single client, single stack, but what happens when you don't? It's like, okay, we need an iOS app or we need a Flutter app and then what? It's like, okay, it's a pretty hard thing to do and then now we have to maintain two. Would you create another REST API or GraphQL in addition to it and that defeats the purpose. And I think the reason we picked GraphQL is to be able to support any language, right? Like let's say you were a Swift developer, you want to write your resolvers in Swift and compile them to WebAssembly, you can. That's the kind of power of GraphQL that it is agnostic. There is no SDK. That's really powerful. It's interesting because, I mean, Daniel mentioned Meteor. I guess, yeah, I just, there's always this, I think once you've worked with Meteor, it's stuck and you can't, there's something emotional that you can't let go of. This full thing that it just works and it's so easy. And I think all of us have this, because at the end of the day, Tim, you worked on GraphQL and Fredrik, you're now building the GraphBase and kind of like PostGraphVal is also something interesting in that, right? Where you assume your database and then you build on top of it. So there's always this, what if I take assumptions and make it super easy and it's not very easy, but then as it gets complex, I can still gradually get into the complexity. I guess this is something, this is kind of like the dream that I guess everyone is just from all kinds of different ways trying to tackle this problem. And I think it's great also that everyone is trying to, because that means there's all kinds of, I think just in this bundle, there's so many different solutions for the same problem, which is really, really exciting. And yeah, I think one thing I wanted to mention again was, we mentioned PRPC and front end stuff and one subject that I was very interested in, like Fredrik, you mentioned live queries. And I think I also saw in Apollo's conference that you mentioned live queries. And I think it's interesting because for me, something that PRPC maybe would never be able to do is co-location of queries next to components. And I think, which I think is a very powerful concept. And for me, that was like the, for me, that was the how moment of GraphQL, like that I can put like my data requirements next to my UI components. But then came the complexity of client-side caching and an overlaid schedule, which everyone has some problems with. But if I think of like the simplest, most, and I'm going maybe again to the Meteor days, but if I would take those fragments and I will just put them as live queries and I wouldn't care about, like, which will be very wasteful, but I wouldn't care necessarily, I wouldn't care necessarily, you know, but being very, very optimized, then I think maybe that could be theoretically like a very easy and powerful first experience of using GraphQL. Because I can maybe, you know, write a React or Svelte component, I can attach a fragment next to it and it will just be updated. Like the data will just be updated there. And then with time I can optimize, maybe get a more complex client, put normalized caching and stuff like that. Yeah, I don't know. This is just a random idea that made me think of things. I don't know if any of you have any opinions on that, or maybe other crazy ideas that you think could simplify or could be like a step change for making a GraphQL experience even easier than what it is today. So I think there's quite a lot of innovation still going on in the GraphQL ecosystem. One of the cool things that I've seen experimented with is this idea of just pulling the data requirements straight out of your components so you don't even need to write the GraphQL queries themselves. That does look quite cool. It's challenging to do right. But it's an interesting approach. And I think we mentioned earlier that there's like the relay way of doing GraphQL and then there's like all of the other ways of doing GraphQL. And I think that the rest of us who aren't using relay, we're maybe not spending enough time actually pulling in some of the really good models from relay. One of the things that I see time and time again is people just not using fragments enough. And fragments is like a fundamental building block of GraphQL, right? Like there's four main keywords, query, mutation, subscription, and fragment. We're not really using that fragment one enough, nearly enough. So I'd like to see that used more. And this like co-locating of the data requirements next to the components works really nicely. And having that work in the kind of defer that Danielle was talking about earlier and having that cascade up the tree, but without delaying the rendering and having ways of that being extracted out of just the code that you want to write. That you maybe autocomplete with TypeScript against the shape of your schema rather than the shape of your query could be really, really interesting. Challenging, but very interesting. That absolutely made me think. So that makes me think it's like CSS and JS, but like GraphQL and JS. I was so happy with CSS before CSS and JS that I was a little bit resistant at first when that became a trend. But then what I realized when I started using it was that it is so much faster because it removes your kind of need to kind of create a shadow DOM in your CSS and just put it in your schema. And I absolutely fell in love. And actually like going back to that moment I was sharing earlier about when I realized, oh, with defer, I don't need to think about how my queries are going to load in my components anymore. I'm architecting my component structure because this takes that away. And now I can just think about my UI again and I can move my data concerns back to my data layer. And then combining that with the GraphQL and JS, CSS and JS idea, I think that's very beautiful. I think the UI should be able to focus on what it's trying to render and the data loading concerns like how fast is this going to be able to load? How do I get the first thing on the page as quickly as possible? You can move that to the data layer with GraphQL, even though it's all kind of intermingled right now. That's a very beautiful future that you wouldn't have to think about the queries and like scaffolding at your queries and having your React components follow the same scaffolding because they're kind of intermingled. I actually hadn't seen that, but that's very exciting. Yeah, that's, I agree. There's one library I think that kind of tries to do that, that's GQLess. I think it moved a lot of iterations. Like now there's the latest one is GQTY. It's interesting. I think those are very exciting new ideas. I think if you break down this, currently I think it's a full client, but if you take this idea of separate the client from the query building and how you build the query, right? Like you have the, let's say the caching layer, the network layer is completely separate. And then how you build your queries, it could be static queries. It could be code written. Like there's all kinds of libraries like GraphQL Zeus and libraries like that, that are code first that are also very exciting, but also maybe something that is like completely magical, like Danielle and Benji said, and maybe something like GQTY. Kind of like, yeah, I agree. It's kind of like, it's magical. Like you just write your React components. You don't care necessarily where the data comes from, which was also similar to an idea from a full client where you had, you basically wrote the query and some of the data of the query comes from client side resolvers or client side cache. And some of it came from remote and you didn't care. Basically you could just write your query. So yeah, if we will have all of this as like an integrated thing, I think it could be very magical and could lower a lot of barriers, you know, for many people. It's very interesting. Which is basically, by the way, that's also the Rails experience. If you look into the landing page of Rails and you just check out the latest block example, so the famous demo 15 years ago, basically you have your templating language and you can just access the data and render it. It's just injected somehow by the environment and just there, and you can build your app. And I think there's still a good reason to use Rails these days. And some companies are able to scale that a lot. Look at Shopify. And it seems like we haven't gotten to the Rails experience yet in GraphQL. There are some attempts to that, but it also, you can't just force Rails again. It needs to fit into the new world. I'm also curious to see where the ecosystem is headed there. I guess actually like in Prisma, when you build the Prisma client, probably you can kind of come up with similar, theoretically you can come up with similar ideas. I mean, I wonder, people actually asked on the, there was one question on the Discord channel, people were asking, how do you see the development, like React server components impact the future of GraphQL? I have some opinions about it, but I think it's very much related to what we're talking about right now. Is any of you have an opinion on when to tackle this question? Many opinions, but I also don't just want to speak. I mean, first of all, there are just question is, does or will React server components be the primary way to consume data in React? If you look at the Next.js docs, they say yes, I know many people who say no. So that's the first question, right? So that's something to be figured out, especially with mobile, et cetera. And then within React server components, I personally don't see a big reason why you wouldn't use GraphQL. You still want like a unified data layer. If that thing, where the code runs after all, I don't think really matters, but it's just my opinion. What I would rather say is that maybe for React server components, if I want to start out with the project and I don't want a lot of overhead, then maybe that's a better approach than tRPC. I don't know what you think about it. It's just about having something quick and easy, but all the benefits where like, again, GraphQL, team collaboration and scaling things, I would still probably use it. Yeah. I think for me, even when you do say, it's kind of like for me, conceptually React server components are kind of like a step in the way of people into the GraphQL world. It's kind of like before that, because it's start to introduce people to the idea that there's no just one route and then you fetch all the data for this one page. But you start to think actually about data and components and rendering on a more granular level. And when like the first lecture of GraphQL that I ever seen, and that when GraphQL was introduced, was introduced together with the idea of co-location of queries, like of basically tied together components and GraphQL. And so for me, maybe it's just, my hope is this is maybe a step, like you mentioned education, like maybe that's one, it's kind of like the initial exercise for people to learn about co-location of queries, which we talked about education. And I think both in the graphql.org and in many tutorials that I see out there, we talk a lot about how to construct the GraphQL query and how that query can then go and call many different sources. But I don't see too many tutorials out there talking about the benefit of, like you said, fragments and query co-location, which I think this is the benefit that I don't see other technologies doing like GraphQL. I think that's the unique edge that GraphQL might have. We don't have a lot of time left. I wonder if any of you wants to maybe give one sentence of what do you hope for the future of GraphQL for the next couple of months. We'll start with Danielle and go around the room. I'm looking forward to landing to for landing stream and building more things into the language like that. I hope that we're finally at that point. Frederick. I'm looking forward to going public beta on graph based. Benji. Faster execution, faster development. Enabling more companies and more people to access data. And I'll finish with just having more conversations with many of the great people that tackle these GraphQL issues from all around different parts of the ecosystem, like everyone here. So thank you so much for this conversation. It was very, very interesting for me. I'm very privileged to be talking to all of you here. And yeah, everyone, if you want to keep asking questions and keep the conversation, we have a Discord channel and you can keep on asking them. More questions there. Thank you, everyone, for joining me here in the panel. And I'll hand it over to Justus here. Thank you. Thank you.

Moderator -
Uri Goldshtein
 
Panelists:
Lee Byron
Sasha Solomon
Benjie
Brielle Harrison