GraphQL 2021 Wishlist- The top GraphQL Opportunities & Challenges for 2021

Hey everybody, super glad to be here. I'm Tanmay, and I'm going to be talking to you a little bit about my GraphQL 2021 wishlist. These are the summary of some challenges, and of course, through those challenges, opportunities that we have as a community in front of us to build more tooling, do a few more specifications and exchange more ideas with each other.

To kick things off a little bit, maybe with a brief introduction. I'm Tanmay, I'm the CEO and co-founder at Hasura, and a lot of what I'm talking to you about is stuff that we've learned from our community, from our user community and patterns that we've seen from our enterprise users, especially. And so with that, let's kind of start things off by doing a quick stock of two things. One, where we are with GraphQL today. So the good news is that we are super... GraphQL has become more and more popular which is awesome, but the slightly sad news is that it's been five years with GraphQL, and GraphQL isn't really yet mainstream. If you think about kind of where, say Kubernetes or CNCF, which was another huge wave that happened in the ecosystem quite recently, it was at a very different level of kind of adoption and enterprise kind of interest and investment as compared to where GraphQL is today. And that's not necessarily a bad thing, but it's just an interesting thing to kind of note that there are certain inflection points that we still I think need to cross for GraphQL to kind of become mainstream. And hopefully the kinds of challenges and opportunities that we're gonna be talking about are going to help kind of understand that a little bit and see if we can build things to solve some of these problems and take GraphQL mainstream over the next few years as a community.

So the two things or two points of context that I'd like to add before we kind of dive into some of these challenges is the reason why people like GraphQL and the use cases are not homogeneous, right? People aren't using GraphQL and people like GraphQL for slightly different reasons. And I think it's important to kind of differentiate between these two. So the first use case, and I'm going to call that a client-centric use case, right? is primarily when we're using GraphQL to help people and help our developers build better UI applications, right? And here kind of what's appealing about GraphQL at a very technical level is that it gives us the ability or it gives the client and the server a contract and an ability to kind of automatically optimize data fetching logic, right? So instead of kind of relying, and this is the n plus one REST API called problem, right? So instead of making many REST API calls to render a particular UI page, right? You're able to fetch that from the application dynamically in a single kind of batched query. And GraphQL is a specification for essentially doing that, right? And here we're primarily thinking of GraphQL as a more optimized API to fetch data. Right. And this is kind of a new problem that's kind of come in when we've moved towards more kind of client-heavy applications, right? This wasn't a problem with kind of purely server rendered applications, things like PHP or whatnot back in the day, where a lot of the data fetching that multiple amounts of data required to render a UI component was done on the server that was rendering the UI itself. And then that UI was just sent to the client that was going to use it, right? But as kind of things become more dynamic, we've realized that making multiple API calls because of just the network is not good. And we need an automatic way of transferring that. Another similar convenience in a technical problem here is that JSON, which was the kind of data exchange format that's emerged over the last decade, was untyped, and it required certain typing, and GraphQL was a nicer technical way of doing it, right? And so this is a very technical reason and how GraphQL is helping us build better UIs. And here you're essentially thinking of GraphQL as just in a very abstract, not completely correct way, a better way to batch and a better way to type, right? That's essentially it without going into the ergonomics of GraphQL. But the second aspect, and the second kind of use case and why people like GraphQL, is what I call a platform-centric use case, right? And here people like GraphQL as a specification to drive a unified API experience, to say that, hey, instead of kind of looking at my one service and it has 10 endpoints, I can have one endpoint and then browse a graph of the models that this API serves. Or if I have multiple services, then maybe I can build an aggregator kind of like a backend for front-end sometimes, or even an internal API aggregator that allows developers to kind of view all of these models together and it becomes easier to consume and explore the API. And this is a big part of GraphQL's appeal, which is this ease of exploration and consumption, which may be a slightly controversial statement to make, but which has nothing to do with the technical performance optimization benefit of GraphQL. These are almost two independent aspects of the use case and why one likes GraphQL. And of course, because GraphQL is kind of a JSON API, it's a great API to interact with when you have heterogeneous data sources or services, being able to view that as one unified JSON graph is great. It's like a MongoDB experience over all of your data over an API type. And this doesn't have too much to do with the technical benefit of GraphQL, which is the batching and there is typing, which helps, of course. The typing is kind of in the middle of both a very technical benefit and an ergonomic benefit as well.

But these are kind of the two lenses with which we can think about the way GraphQL is kind of being adopted, used and loved by people when they're using GraphQL. And so when we think about the challenges in the next few minutes, let's keep these two kinds of use cases in mind. So the first is GraphQL clients and fragments, which is primarily client-centric use case. And here, the challenge is that when we think about going beyond the convenience of GraphQL and really kind of optimizing and automating high performance data fetching, it's really hard to do that without good fragment-based tooling.

Fragments are critical and tooling around fragments is critical to automate the heavy lifting and the grunt work of building a UI that kind of composes all of its requirements together into a single query and fetches that data. And here, again, maybe a little bit controversial statement, fragments are, in my opinion, not very useful for reuse. It's not like I'm not particularly excited about creating a separate file where I store all my GraphQL queries and fragments and then I refer to those fragments and use them in my components. That's not a particularly exciting use case for fragments for me. I'd rather just specify the query next to my component. I'd rather co-locate my data fetch requirement within my UI component as a developer. Instead of touching 10 different files, I'd rather touch my component file.

And in this case, what fragments can really allow us to do is to, me as a developer working on a particular UI component, I can work on a single component and I can specify my data requirements as a fragment. And multiple people can work on different components, specifying their requirements as a fragment, which automatically get merged. When all of those UI components come together in kind of a UI component tree, all of those fragments will also get composed into a single query. The beauty of this approach is that it has to happen automatically. If this is happening manually in the sense that I write a fragment here, then I have to import the fragment somewhere else. And then I have to specify that, Hey, I'm using this fragment. I have to go to the top level component and specify my top level query that I'm using a fragment somewhere. It's not a great experience. And it's kind of the benefit of using GraphQL to automate this data query composition stuff is lost.

Now, Relay has done a fabulous job at kind of taking these several concepts that are required to compose data fetching logic automatically. And the tooling that is required to automatically deal with fragments, right? Without having to do the manual work of writing fragments, maybe in a separate file or importing and reusing them and whatnot. But unfortunately, this idea has not come out from the Relay clients, because the Relay compiler is also a little bit complicated. But taking that Relay compiler and using that to build other GraphQL clients is something that we need to do more of. I think there's some interesting work that's happening here with some of the clients. I think if I'm not wrong, the Angular client. But there's a lot of interesting ideas here that we need to take beyond just the React ecosystem into other UI ecosystems as well. Alternatively, there's a lot of love that we need to give to the Relay docs and to get that up to speed so that that client is kind of more usable and more accessible, right? Interestingly, there are other approaches that are emerging to solve a similar problem around data fetching and optimizing data fetching automatically, right? SWR, which is Stale-while-revalidator, the name of a concept but also the name of a library or a tool that the Versal folks built, and Vulkane, which is another approach using HTTP2, are very interesting approaches that allow kind of the similar idea of letting UI developers build their UI components, specifying their API call that fetches data, but then kind of having some of that data fetching logic get automated without developers having to do too much work to kind of compose that together to redo stuff and to make it as efficient as possible, right? And so there's interesting non-GraphQL approaches or can have some overlap with GraphQL as well. And the interesting thing about these approaches is that because they're not reliant on GraphQL, they don't have to add any of that GraphQL complexity. And so this is one area of work that I'm particularly excited about and hoping that there's more stuff that happens over the next few months.

I did a talk recently at React Summit a few months ago talking about kind of this idea of relay and fragments, which was kind of my journey in understanding a fragmented relay-based approach, and it completely blew my mind. And so if you're interested in this topic, that is worth a watch. Sean and Gabriel put together a great blog post series and introduction to relay, which is also worth reading through and understanding these ideas that make relay, and especially some of the fragment-based tooling, amazing.

And then, of course, these are the libraries, Vulkan and SW are also worth checking out and understanding.

The next problem I'd like to talk about is having native GraphQL clients beyond UI frameworks. And this is, again, a slightly more platform-centric approach that I'm talking about, where you have this API and you're not necessarily going to use it in a UI, you might use it in a UI, you might use it in a desktop app, you might use it in a service. I think that's one of the things that was great about REST, which was that there was no actual, like, when people build rest endpoints, there's not, it's not a very specific standard that everybody's following. There is a very specific standard, but people are fairly loose with it, and it's very flexible and people do a lot of things. And that made it easy to kind of start integrating REST. There's a lot of optionality in being able to integrate the REST API with whatever you were building, whether it was a UI or a service or whatever, right? GraphQL today is extremely optimized for the UI, but making a GraphQL API usable in non-UI frameworks also has a tremendous advantage because it de-risks the people who are building these services, right? Somebody as a developer building a service. If I have to build a GraphQL service and a REST service, not fun, right? And that's kind of one of those big risky things, which is that if I build an entirely GraphQL, if I build a full GraphQL API and tomorrow some other clients need REST API, right? Other developers or other teams or other applications, then do we maintain both APIs? And so that's a lot of work, right? Because it does seem like in the GraphQL versus REST conversation, it's going to be more of GraphQL and REST rather than a GraphQL versus REST, right? And so one of the critical things required for that to happen is some more work on the kind of GraphQL client tooling, right? And I think one of the challenges here is that GraphQL APIs are not necessarily easy to consume and integrate because they're too flexible. This is not a bad thing from a kind of a developer point of view, but maybe from a integration and stack point of view, it's a little bit of a challenge.

One place where this shows up is when you're trying to code gen types, right? If you have a different query that fetches the same different slices of the same base type, right? You might have a new type for every query, right? And then you have like a explosion of types on the application, which is not necessarily a problem, but could result in some problems. Rob Zoo talked about, you know, some advanced kind of GraphQL client magic that they had to do on the Java Android app side of things so that they were not triggering excessive garbage collection, right? And so when we kind of think about bringing these ideas of a better GraphQL client, that kind of has lesser, you know, and lesser explosion of types for every single type of query that you make, or a more optimized consumption experience, I think that's going to be critical in helping GraphQL adoption become kind of more smooth for developers, you know, whatever they're building.

Two of the approaches that I'm excited about here are of course the great work that the GraphQL code generator folks are doing in the community there is doing, but also approaches like Juke in the SQL world that provided kind of native abstraction to SQL as opposed to an object-based abstraction to data entities. And I think GQLs by Sam Denty is another very interesting idea and approach that I think Sam started that this year, that makes a more native consumption experience for GraphQL possible. Of course, most of this is happening in the TypeScript and JavaScript community, be interesting to see this kind of move to beyond just the JavaScript and TypeScript community.

All right, next up is this challenge of bridging the GraphQL to REST tooling gap. So the cool thing about REST APIs and the entire REST APIs ecosystem is the immense amount of tooling, infrastructure tooling, vendor tooling that has been invested into helping people operate and deal with REST APIs introduction, right? Specifically health check and quality of service monitoring, right? So you can stick in a vendor tool without touching your stack. You can just integrate, drop in a vendor tool that will start giving you a status page or a health page that tells you what the quality of your API is, right? What is editing out 5xxing, 4xxing, stuff like that, right? You can set up alerting and monitoring fairly easily again, without doing too much work. By using this kind of, by using a vendor tool or by using an infrastructure tool without affecting your work, or your application logic, or your application server too much, right?

And here the problem with GraphQL and one of those things that we still don't, I think have a good solution for is that GraphQL returns errors inside the response body not inside status codes, right? And in fact, it can be partial errors, right? And there's no notion of partial errors in a status code. So what this means is that the tool that we're using to do our quality of service monitoring or error reporting or alerting has to actually peak inside the response body to understand whether there's an error or not. And this is a challenge because the response body is very kind of critical private data. You don't want to take that data and send that to a third-party tool for analysis, right? Because that's essentially like very sensitive private API data, right? And so there's challenges here in kind of being able to bridge that. Of course, server-side caching is a problem that we've been talking about from the dawn of GraphQL times in being able to leverage the various kind of network points that are between a server and a client, right? Everything from a CDN to the load-balances to servers in the middle that will make sure that we're able to send, do some element of server-side caching, right? And indicate to these various network points in the middle what caching policy we want. One interesting idea potentially could be to have some kind of automated human-readable mapping from GraphQL to REST, right? It has to be automated so that as developers building or using the GraphQL API, we are almost kind of not worried about it, right? There has to be enough, it's kind of almost similar to a persisted queries idea, but taken a little bit further. And maybe it looks something like this, right, where you say you have a query, you parameterize the variables, and then you convert that into an idiomatic REST endpoint. So that in production, you're actually just using these idiomatic REST endpoints and everything about your tooling works, but during development, you get to use all of the greatness of GraphQL, right? Kind of similar to this idea is also this idea of using GraphQL as an intermediate representation and not final API. And this is really that kind of platform-centric appeal, which is saying that people really like browsing GraphQL APIs and GraphQL, right? If it comes to actually using those GraphQL APIs in their applications, because of all of the challenges that we talked about, right? Or if it's a service, they're not consuming it inside an application or a UI. Shrug emoji, right, which is that basically people are not terribly excited about changing the way they think about their API clients in whatever that they're building to use GraphQL.

And so here, is there, you know, could there be ways for us to get the benefit of GraphQL from the exploration, tooling, documentation, browsing, getting that right slice of data, right? All of those benefits, without having to change the way our API clients work. And kind of related to that previous idea is that if we could use GraphQL as an intermediate step in our API lifecycle, right? So we can say, you know, I want an API as a developer, I wanna consume a particular API. So I go into GraphiQL, I try out like whatever GraphQL query I want. And then I kinda submit my GraphQL query and I said, this is the API that I want. And then it goes through review, either automated or human or whatever, right? Maybe a performance check or whatever check that you wanna do. And then I, you know, in development or during development, I get a REST or a gRPC or whatever endpoint that we are actually, that we have all of the tooling set up for, right? And here we can kinda get the metadata catalog, the data dictionary benefits and the API exploration benefits of GraphQL. But without having to get, without having to force our users to actually use GraphQL introduction, so that they have to reinvent that tooling, right? It's kinda similar to the previous idea.

The next problem that I'd love to talk about here is that when we think about various different GraphQL services that we want to stitch together, there are some interesting challenges. It's imagine, for example, if you have multiple relay schemas, right? And you want to kind of, you have this GraphQL gateway or some kind of aggregator that is kind of delegating to the schemas, but the schemas are not just GraphQL schemas, they're relay schemas, which means that all of them, for example, are going to have a node field, right? And they're going to prevent a node field. Now, when you try to aggregate them, you can't just clobber these schemas together and put them into a type, right? You can't prefix them or namespace them because that doesn't make sense, right? The node field has certain semantics associated to it, the ID field that every type would have, also has some certain semantics associated with it, and namespacing it or prefixing it or just clobbering that together into one API is not helpful. And so here, what we really want to do is have the services kind of exchange more information. Let's say, for example, in our organization, we've created certain kind of these common standards, these interfaces, similar to the node interface that we want to use. How do we exchange this information with each other and in the gateway, right? And augment that kind of introspection result, maybe it's extra things on the SDL and stuff of the extra directors on the SDL or separate API or whatever. But this is kind of essentially the work that we have to do, which is that you're basically delegating to these other services and you have, and you're kind of using, you have to re-implement the node field as a GraphQL resolver at that kind of GraphQL aggregation layer, right? And then that delegates to the node field in these upstream services, right? And then you have to make sure that you can manipulate the data, the ID response, right? Each identifier has to be changed at the aggregator level so that the identifier has the indication of which service it's coming from so that then you can delegate it appropriately, right?

I think the last two quick ideas that I'll cover, and these are two short ideas, is the idea for role-based schema, which I think is particularly appealing, especially inside very large enterprises. One of the problems here is that it's really kind of nice sounding to say, what if all of our APIs are one gigantic centralized, universal GraphQL API? It sounds nice, but it might not actually be nice if you have 20,000 API end points or resources, right? Because then it's just too much. And what you really wanna do is whenever I enter graphical, I don't want to see so many APIs, right? Let's say it's an e-commerce situation, I have a separate merchant API, consumer API, and an ops API, right? Ops is somebody internal to the org, say. In these cases, I don't want the merchant folks to even see the consumer API, right? I don't even want them to try querying for stuff, try bothering in putting a token and getting a null result. I don't even want them to see that part of the schema, right? And so here, this idea of kind of linking that authorization or the identity of the consumer to the schema that you're getting, right? Where it's kind of dynamic, it's not like a built-in schema that you've had at build time but it's a dynamic schema that reflects the user that is actually using it, is very useful. And makes it kind of platformy style of consuming GraphQL very convenient. The last thing that I wanna touch upon, which is really kind of a set of things to be aware of is, as WebSockets and HTTP2 and HTTP3 mature, there is some interesting work for us to do as a community. Keep kind of pushing GraphQL and making sure that the GraphQL specification or specifications for particular ways of using GraphQL, maybe not the core specification itself, is evolving continuously as well. And especially with AdDef or AdStream being added as experimental features to the GraphQL spec. Integrating that with WebSockets, today, for example, it works with multipart form on HTTP1, but integrating that with WebSockets and then HTTP2 server push or HTTP3 server push is also going to be quite, will also be quite interesting. And here there will be some challenges in the way that we handle stateful workloads because essentially these... Essentially when we're kind of doing more of these dev-force stream or push style things over newer protocols and over newer styles that could be more efficient, these workloads are stateful in the sense that, you know, if somebody subscribing to something, they can't suddenly switch over to a different server that is serving those subscriptions, right? And so there is a little bit of work that needs to happen in the backend itself on how we're able to handle these things particularly from a load balancing, scaling and security point of view. And so those are some interesting things that are happening. There should be three, still very experimental and very new, but there's some interesting stuff that's happened there that is useful and should be, will be good for us to keep evolving GraphQL in that direction as well.

All right, so my apologies for being a little bit over time and with that, I shall close this out. Please feel free to reach out to me, talk a little more about this and excited to kind of keep engage with you folks talking about these challenges, learning about other challenges that you're facing. I am Tanmay Go on Twitter, please do feel free to reach out and I'll of course, I'll make the slides and resources available so that you can check them out as well.

Thanks for having me. Hey everybody, thanks Fish. Good, good, good, good. I hope everybody's doing well. Yes, that was an amazing talk by the way. Thank you, thank you so much.

So, what do you think about the results from the poll? Was it expected? So, that was my gut feel. My gut feel was that more people are going to vote for GraphQL for the API integration and onboarding and the community tooling experience. And, lesser for the theoretical benefit of GraphQL, the N plus one performance difference and the type safety, which was a large part of the original design of GraphQL and why it was built, right. So, it's very interesting to see that difference and I think that's kind of, that shift of GraphQL kind of being more important for API integration and onboarding is what's kind of one of those, what's kind of one of the core ideas behind, the set of problems that I highlighted over the top, because I think there's, I think if you think of GraphQL for those aspects of the API onboarding integration, there's still a tremendous amount of work that we still need to do to make GraphQL easy and more mainstream.

Definitely. And I think that was a great question to sort of start the talk with. So that was really interesting to find out about. We also- Yeah, I was also very genuinely curious. I was like, wait what is gonna happen? Is it, are more people going to be like, well performance is important? Or are more people gonna be like, you know, I love GraphQL because it's just a great API. So it's interesting. Yeah, absolutely. We also have a question from Discord and a little buddy dropped it for me to ask you. So question from Bosjan. When half the world is on GraphQL, what are the challenges that you predict? When will we be joining various Graphs together? Yeah, that's a good question also. Hey Bosjan. I think, yeah, I think, so if, I don't think there's ever going to be unfortunately a world where everything is GraphQL, right? So there's going to be a percentage of things that move to GraphQL. I say this with all the love for GraphQL. So I don't think that's going to happen, but it'll be interesting to kind of see those use cases emerge, right?

I think there are two broad cases that I see for people wanting to join, to kind of join quote unquote graphs, right? One is this kind of, the first level of problem that a lot of us are dealing with, which is that we have kind of many different API endpoints and we have front ends to build, and it's just a gigantic pain in the neck to be able to look at all of those different endpoints and combine them on the front end or some back and forth front end thing and come up with an API spec for it and stuff like that, right? So that's kind of this one use case of maybe not even necessarily joining graphs, but maybe creating a common, a GraphQL model or a gateway or a aggregation layer or something, which is essentially a better API batch or API gateway, right, it's like a version two of that, it's a programmable API gateway maybe of sorts. And that's kind of one use case that's emerging, right? And the interesting thing there is there's lots of alternative approaches to that part of that problem as well. A lot of people are like, you know what, let the micro services and API endpoint explosion happen, we'll figure out a different way to fix that problem, and Vulkan that I kind of talked about is a great way, great approach there. But the other kind of approach for joining graphs and joining data, I think is not necessarily just in the front end community that most of us are a part of, but also kind of just the API and the data community, right, which is the people who are kind of, maybe inside a large enterprise, you have several lines of business, right, you have, or even in a startup, right, you have people doing all kinds of things, right, not everybody is necessarily building the app, that's perhaps one big part of the business, but there's lots of other things happening as well. And for a lot of them, they kind of need this ability to say, well, here's my core data, and then here's some additional data, here's some data in my SAS service, here's some data here, and I want to have like a common JSON model across them, right, and I think being, and I think being able to deliver on that use case, that's when we're going to see a lot of interesting kind of, we're going to see another round of pull for GraphQL, or for GraphQL-like thing, to say let's join those graphs together, right, so I think it'll depend on the use case. I definitely do think that like, we have to kind of bridge that gap between GraphQL and existing API services and API tooling and API vendors to make that happen successfully though, so let's see how it works out.

Yeah, definitely, there is a lot of hype around unified GraphQL data access layers.

I think that's something that everyone is looking forward to and is really excited to see. Yeah, yeah, yeah, and let me just to add a note of caution there, which I was talking about in the panel discussion yesterday, right, like the idea of a unified graph sounds very appealing, but you have to make sure that you're unifying it for the right reasons, right, like for example in a large enterprise, you don't want to have a unified graph of your entire API ecosystem, right, because you'll go mad, like you look at the one million APIs and you're like, I don't want this, I just want those three API endpoints, right. I just need to do these three things. I don't want to see all these million interconnected things because these are the only three things I'm interested in. So I think that the use case for unifying the graph is going to be, or like, or unifying data, right, if you have started to level more, is I think going to be very interesting to look at.