GraphQL Everywhere

Hi, and welcome to my talk, GraphQL Everywhere. This is going to be a very fast talk. There are going to be a number of hot takes in here. And I think that at the end of this talk, we'll all have a number of things to discuss or think about or patterns that hopefully are maybe new to you or ones that will at least challenge some of the preconceived notions you've had about exactly where GraphQL might actually live.

Before we get into that, I want to go ahead and tell you about who I am. I am Developer Relations at Hasura. Hasura is a GraphQL company. I'll explain that here in a minute. I've been doing Developer Relations for GraphQL for roughly five years, and I come from a background in product and design. Some of my observations are going to be, as I described in the title, a practitioner's take on what GraphQL has been, where it's going, and mostly from a builder's mindset.

My name is Jesse Martin. I am a dad of four. That means that there will be a number of dad jokes dropped throughout this chat. I do apologize, but at this point I can't actually help that. You can also find me at MotleyDev. You'll see that Twitter handle there at the bottom of most of my slides. Who knows how long that's going to be good for. So definitely hop on that before that one's gone. But I want to go ahead and actually give you a quick overview of who Hasura is, the company I work for, because that'll give a little bit of context into where these observations and this pattern is coming from.

So first of all, Hasura is an open source tool, basically. And what it does is it gives you GraphQL on your data sources. It'll give us a database or a couple of other data sources at this point, and we'll actually generate the endpoints for you, the resolvers and things like that. Of course, you can customize them and all that kind of behavior. But at the core level, there is this idea of an engine that is interpreting one schema and conforming it or transforming it into another. That's actually going to be really important for us to have a look at later on. Think again Hasura Engine and also think again Hasura Open Source. I like to say, pay me if you want. And so what it does is it gives you very robust access controls, and we have a very powerful predicate push-down model. Basically the authorization takes place at fetching time, and so you're not actually over-fetching from your database. You're able to actually say, we want to have a very lean, very terse select set from our underlying data source.

And yeah, it supports custom business logic as well, event triggers, actions, and all those kind of behaviors you would expect from a data-layered tool. But the last point that I really want to hammer home, especially in times like these, is that we're hiring. So if you actually are in the market, if you're even dev rel, I want to talk to you. But we actually have a lot of openings across our business. And so we are hiring, definitely reach out if it's something of interest to you.

So kind of where does this sort of sit in the big picture? Well, you'll kind of see it sitting in this sort of a layer where authorization, authentication happens externally. And you'll usually get a JWT is kind of the most common pattern. And then those roles get applied at fetch time. So like underneath it all what kind of happens is that you make a query, a GraphQL query, and our engine will actually map that to what the underlying data source understands. In this case, SQL, right? And so this is the way that our engine kind of operates at a fundamental level of letting you do this. This is a widget we have on our homepage. You can actually try it out interactively if you're curious, and there's a lot more information to be had on there. I did say it's open source, but this is not a side gig. So, I mean, it's a really big tool. We do have cloud versions, we have enterprise versions, we have a lot of major, major companies that are running on us. And so if you're looking for a GraphQL adoption at an enterprise-ready scale, reach out. We have a lot of interesting tools that might be of interest to you, and we have a really powerful go-to-market team that's just there to answer questions and get you going. So have a check.

OK, that's the Hasura stuff out of the way for now. And so what I really want to talk about next is that we have, for this talk, I have a couple of assumptions that are really, really important for you to actually bear in mind. Sorry, the benefit of recording from a home studio, right? So here are some assumptions that I want to have you really take with you into this talk, and that is that basically I am assuming that you will know a little bit about GraphQL and kind of what it's been used for up to this point. I really hope so because it's GraphQL conference and the other part of it that you need to be aware of is that some people on the internet get angry about really silly things. So those are the two primary points you need to understand to be able to go forward, and you'll see sort of what I mean by some of these later on. But first of all, so strong opinions loosely held but strongly inferred. I'm looping back to this practitioner's angle again. So these are things that I have seen in the market across multiple GraphQL companies. Now these are things that we have seen, but end of the day, haters gonna hate. So let's go ahead and start. So these are some of my opinions that have been formed from observing GraphQL at a number of different companies, both from the GraphQL provider as well as from the consumer. And that is that REST APIs are still very dominantly preferred by single service providers, people that actually are gonna be shipping an API for general consumption across the market.

But GraphQL is preferred by multiple service consumers. And we're gonna have a look into why that is. But I mean, right at this point, you're like, well, that's like your opinion, man. But there's a reason why I've seen this. And there's a reason why I think this is held true. And that is, look at the actual ecosystem right now around building with APIs or building with different data sources. And the data access challenge becomes really, really complex.

We have a number of different data sources, a number of different microservices, a number of different platforms and other tools that we're trying to sort of stitch together. And each one is bringing its own SDK or ORM or other kind of API concept to the party. I mean, it's nice when we have open API specification that a lot of people can adopt. But that can be really spotty at times, as anybody who's built with application APIs lately even knows. And so we have a situation where the data access challenge is really problematic because it's just spread all over the place. And so when we're looking at specifically our microservices, this becomes a really pronounced problem. But we're going to look at that down the road, because I don't want to get ahead of myself here.

And so when we think about it, what would be kind of really cool from a data access perspective is what if we could just kind of use these data APIs and these services and just sort of kind of merge them all together into a single mesh where this service can use the same API that it's a member of to access other parts of the data. And so this is a concept that we're trying to kind of talk about, about this idea of a single API, where GraphQL gives us this ability to say we have one, one single API that actually federates across all these different pieces. So this is a really critical concept about why multiple data consumers are data consumers of multiple data really need to have access to all that in a single API because it's just one end point and one type of way of querying that data that lets them get access to their content. And so I want to go a little bit deeper here. And the reason is, is that when we look at why REST has developed the way that it has, or that the people presume like REST when it comes to delivering an API, is that it's really easy to model around deliverables, right? Because you have a pretty well defined scope of what data you're shipping out, and you have a pretty well defined scope around how you want people to access that data. But as soon as you start to have to model around different kinds of consumption patterns, you see that GraphQL quickly becomes a favorite tool because it's really easy to model around consumables, around what is this product that I'm trying to build, and what's its data requirements going to be? And then suddenly, I'm with a graph and I have to figure out how do I actually get all of these different data sources in a streamlined, resource-friendly way. Now I used the word model on purpose, because when I say it's easy to model, it is easy to model, but it's not always easy to implement. So I want to go ahead and talk about that also a little bit later on. So let's have a look again at what the GraphQL benefit here is. So this is why I like to refer to as Metcalfe's Law for GraphQL. And if you're not familiar with Metcalfe's Law, the more nodes that a graph has, the more value that it has, right? This is the social network theory. And so with GraphQL, it's very much the same way, the moment that you add more and more data sources, you get a lot of value from it. So let's have a look at some abstract models here. How does this play out? Well, if you look at something like a bunch of diverse data models here, we've got a scooter, coffee and a user. This sounds like a really bad day in New York. But if you take all these different nodes and if we kind of flesh it out a little bit into additional pieces of content, now we want to bring in things like weather and maybe like charging stalls and locations and battery status and other kinds of pieces of this data, well, suddenly we're actually looking at a recommendation engine for, hey, you're nearby this coffee shop and you've got some need to charge, why don't you stop by, charge your scooter and get a coffee? Or other behaviors.

The value that we're able to build and extract from diverse sets of data becomes really, really powerful. And the reason why then GraphQL makes this all really helpful for us is that to orchestrate this, there's less overhead, because I've just merged all the pieces into a single API, I have a smaller control plane, I'm not having to worry about shipping around my environment variables and everything else. I've got reusable patterns that I can reuse over and over again at different tooling. And it's like totally agnostic to the consuming application, if I'm shipping an Android application or an iOS application or whatever it might be that doesn't matter. And that agnostic part is actually really, really, really critical because I'm arguing here that that API has value for us across a number of different contexts, not just front-end consumers.

Well, let's go ahead and dive a little bit further into the theoretical models here. So what we have here is sort of your common GraphQL service structure, right? You've got your order product, you've got for reads, and then log in, log out, purchase, and editing your orders as mutations, or roughly speaking. And so you've got maybe SQL services or REST services identified for the data you need on the one side, and then on the other side, you've got micro-services for logging in and logging out and resets, and that's kind of roughly how this data sort of plays together. Well, you'll see that the data dependencies of something like a purchase, we need access to all this data. But something like a purchase model might actually be protected context, right? Because we're talking about mutating a database, or we're inserting content, or wanting to have data that's potentially interfacing with our database, and so we want this federated of data dependencies in the context of wherever our service might be running. So if that service happens to be purchased, we still need user order and product, but why can't we just get access to that data, like, at the execution time? And we're going to talk about some of the reasons people say that you can't, but let's go ahead and break this into a bit more of a less abstract model.

What happens if we were to say that the data model we're actually working with is way more complex, right? So we've got, you know, network credit average, we've got pending purchases, historical income, we've got the history of the users' returns, blah, blah, blah, what we have here is a risk assessment model. This is highly protected data. This is something we would like to be able to get information from as a feedback to just kind of wait, whether or not this person has a risk assessment for a credit score or whatever else. It's like, we need all this other data, which is going to live in very different silos, to be able to come together to make this weighted calculation. And so what I'm arguing here is I'm saying that, you know, we have the query coming from the client, from the front-end client, trying to get information about, am I approved or not approved, whatever it might be, but then that same protected environment can actually make a query itself with the same data API that I was able to call from my front-end client with the same API endpoint from the actual risk assessment service back to my same GraphQL API and get the entire data picture that I'm looking for to be able to make that calculation. Why do I, all of a sudden, do I need to actually break out into an entirely new environment for all of this data? I want to be able to access this data at the place that I need it. And so, then, if I can make that calculation, I can work with all the data payload I need for my calculation, I'm reducing the amount of round-trips and everything else that I might happen to need. Well, this isn't actually just theory, right? This is actually something that we see implemented everyday, at Hasura specifically, across healthcare, across reverse ETL things, DORA metrics, we have food delivery companies, all kinds of different services that are having to deal with this data.

Now I wanna go into some dissenting opinions and, as I say, also here, everybody's allowed to be wrong, but one of the arguments is that it's not what GraphQL was created for. I argue that, well, actually, it is totally what it was designed for, to be defining your data dependencies for an execution. Yes, it wasn't in the front-end context to reduce data over the wire, but it was about getting the data you need in the context you need it. Well then, what about latency? Okay, so, marginally higher than potentially a very optimally designed REST API, but that too is a solvable problem, so I want to cover our approach to that. So when we move on here, talking about our solutions for that, we want to do the gotchas, and there are none, so we can just go. So when we talk about latency, there are actually solvable problems for this, but this is something you have to bear in mind with the data model. This is true for any API, but generally speaking, the user can wait, right? I would be happy to wait an extra one to two seconds, if the service worked the first time and didn't have a hangup on the API side. The second piece is new API, new problems. So potentially we're actually just shifting all of the errors or the issues we had with best-consuming patterns for our microservices just into an entirely new context where we have to build out all of this new infrastructure to support microservices consumption of GraphQL. And here's where I really want to kind of hammer here. So we actually have a new API, but we have a hero emerging.

And so Hasura is building off of this experience we've had helping customers implement these patterns. And we're now actually introducing a new tool that we'd like you to have a look at. And that is actually the GraphQL data specification.

The GraphQL data specification, very specifically, is a description or it's a DL that is a description for what underlying data sources might look like. How can we connect these data sources across different entry points? What do edges look like? How does it resolve? We're abstracting away the underlying data source at the moment for us. We use a database schema. We're abstracting that away into saying, let's have an actual DL that we can feed into an engine. And that engine will actually allow us to be able to read or be able to create the APIs that we need from GraphQL to support this.

So this specification says, yes, microservices execution is great, front-end execution is great. But the bigger picture here is defining what your data needs are. So use a tool like this, use a tool where you can define your entire data layer inside of a DL, and then feed that into an engine and be able to actually have that interpret and create the content you need. That's a really, really powerful way to work.

This is a very, very alpha request for feedback, get-involved, community-driven thing that we're releasing here. We would love to have you get involved with this and let us know what your feedback is. You can try out this playground here. We'll drop the links inside of the chat where you can find this and be able to actually test it out for yourself. So it's the GraphQL data specification. It's on the Hasura GitHub repo for right now. You can find it there. But we would love to have you have a look.

That being said, that's actually my last slide. I want to thank you very much for coming out today. If there's any questions, feel free to drop them in chat and I'll try to answer them. But again, thank you so much for watching this talk. I know it's fast. I know there was some hot takes in there. But if you have any questions, find us on Discord. Find us inside of our community, GitHub issues, everything else. Try out Hasura. Use the Hasura cloud. It is the fastest way to get going with Hasura. There's a free tier on there. But we think you're going to love it. And we can't wait to hear from you and see you on the community.