Panel Discussion 'The Future of Server-side GraphQL'

Let me introduce those distinguished guests, starting with Benji from GraphL. GraphL 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 Shuchanik from Stellate. He's the co-founder and CEO of Stellate. Tim was the first employee at the first GraphQL backend as a service, GraphQL, 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 Stellate. And Fredrik Georg 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. You know, this panel has a very big title, What is the future of GraphQL? And I think there's, all of us probably have a lot of different perspectives from all of the many different areas that the people here are a part of.

So maybe we can start with Benji. Just in very, let's call it general terms. How do you see the current trends in GraphQL? Where do we start 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 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 specs. 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 basically probably think so much of user stories and 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 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 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. I'm excited about GraphQL all over again. And so I'm really excited that we're entering this phase of defer, live queries, caching, 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 the biggest conceptual thing that people can now do with defer? The biggest a-ha moment for you when you started playing with this? So my a-ha moment, we have a big front-end app at Apollo called Studio and every time we load a list of things, we 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 the metadata on that list can load more progressively. And so when you just load one page, it's maybe like 100 queries, which is just so many. And so I had this a-ha 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 exciting.

Yeah, I agree. And you also mentioned live queries. And I know that GraphVis has started playing a bit with those things. Maybe you can take the question from your perspective, Frederick. 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. And 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, 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 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 care deeply about because we want to make GraphQL servers easier. Because I think the kind of common knowledge, at least in my experience, has been building GraphQL services is a bit hard and fragmented. So that's something we're excited to make better.

Yeah, that leads me to the next question. I agree with you that we got to the boring phase where we know more or less what is GraphQL. We have these things, but now there are some challenges. I think probably someone who's been into this problem for so many years is Tim, because of GraphQL. Right? Where you're one of the first that actually looked at how to make it as easy as possible, as simple as possible. And you've been through a lot of waves and iterations over these six and a half years. Where do you see the current challenges of where we are in, and what would be the easiest wings moving forward for the community? I think 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 is a collaboration tool. It brings people to the same table and they can talk about something. And now 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. Once you identify it, now you can see if there may be a tool that can help us. And I think that's like a few steps down the road. And it's a lot of education that needs to happen to really get like the benefits, like also relay style, GraphQL is also still quite different than what is using let's say a lot of, let's say starter projects. And people have like 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 like working on something to make it easier and move GraphQL forward. And it's a huge, like it's like 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, it's holding us together.

And I think as long as we all move forward and that's like, the spec is combining all of this, it's 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. There's education also sometimes means people need to know more things or to, you know, some things are just make sense when you're getting into more complex applications. But I always ask myself, can we build better tools for the beginner, where you know, you start easy, you get what you want, and then you just gradually, you know, you 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'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? Maybe Danielle, you 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.

On the Apollo side, we have a lot of tutorials, we have our Odyssey learning courses, we have a lot of docs with getting started guides for... Yes, how do you write a resolver? Yes, 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.

Benji, I was actually 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, so I'm curious how you think about teaching people how to do GraphQL while on the back end. 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 then 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 you 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 an input object and a payload object, and various things like that that people might initially think, I don't need all this stuff. 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 costs 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 back end, 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 like 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 solve, to build graphical servers on the backend? Do you see other interesting ideas? By the way I saw a glimpse of Graphast is very exciting, but I know that both team and both teams and Frederik have also interesting ideas there. Frederik 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 you know 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 that's the problem we want to solve and that's 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, aiming for minutes instead of days. Starting with a simple schema-first approach but considering the benefits of code-first at scale. The goal is to streamline front-end developer deployment of GraphQL APIs and gradually engage full-stack and back-end developers in server deployment. The evolution of frameworks in the GraphQL ecosystem aims to simplify adoption and cater to diverse developer preferences, similar to the evolution seen in React frameworks.

Exploring the shifting boundaries between front-end and back-end development in GraphQL, leading to a broader understanding of data source implementation and varied roles in GraphQL APIs. The complexity perceived by front-end developers in using GraphQL prompts discussions on simplifying the front-end experience and potential alternatives like PRPC. The community's feedback on GraphQL's ease of use for front-end developers sparks considerations for enhancing simplicity and usability in GraphQL implementations.

Continued innovation in the GraphQL ecosystem introduces concepts like extracting data requirements from components, emphasizing the underutilized power of fragments, and co-locating data needs with components. The analogy drawn between GraphQL and CSS-in-JS highlights the potential benefits of segregating data concerns from UI components. Exploration of the future of GraphQL involves integrating data requirements seamlessly into components, potentially simplifying the GraphQL experience and lowering entry barriers for users.