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.
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.