 All right, cool. So we'll get started in just a sec. Glad to be here, glad to be in person, attending one of the first few conferences of the year in person. Hopefully, none of us fall sick after this. I was here last week for the OpenJS con for the same venue. We were doing the first GraphQL conference, which is vendor neutral conference organized by the GraphQL Foundation, so I'm happy to kind of be here again. It's barely been like two weeks. Thank you so much for making it here. Hello to folks on the live stream as well. I'm going to be talking a little bit about GraphQL APIs in the context of data and over a few data mesh type architectures as well. As a quick ground of introductions, I am Tanmay, I'm the CEO co-founder at Hasura. So I'll talk a little bit about Hasura and GraphQL and then dive into the agenda of the talk. Hasura is an open source project that we created in 2018 and the idea is to provide an instant real-time GraphQL API on the data that you have in your organization, connect to various services, various data sources, get a unified GraphQL API that solves for things that you would want to solve for the API layer, which typically end up being three main problems. The first is you want a semantic JSON kind of model at the API that you want exposed to API clients. The second is a performance, speed of light, caching, caching complex queries kind of problems. And the third is security and authorization problems, which is the reason why you have an API layer in the middle in the first place and things are not accessing data systems directly. Hasura is an open source project, Apache license. Since we launched it, it's been one of the fastest growing GraphQL, open source projects in the GraphQL ecosystem. You can check it out on GitHub. GraphQL itself is a specification that came out of Facebook that was open sourced a few years ago. It was open sourced a few years ago and then donated to the GraphQL foundation that was then started a few years ago as well. So 2016 I think is when the spec was open sourced by Facebook and a few years later the GraphQL foundation was formed. So the GraphQL foundation is a vendor neutral body. It's a part of the Linux foundation, sister rock to the CNCF for example, we're one of the founding members of the GraphQL foundation as well. And that foundation body governs the GraphQL specification and I'll get into GraphQL in a bit. But the important thing to remember is that unlike say for example, Kubernetes, GraphQL, the GraphQL open source project is more of a specification and not really a runtime. So you'll have various different vendor products or open source projects or your own implementations that would implement the GraphQL spec very similar to the way you would have a REST specification. And then that's how you'd implement a GraphQL spec in a GraphQL server for example. So Hasura is a GraphQL server in that context. Cool. So before I get started, just a few quick questions for you folks. So how many of you have heard of GraphQL before this talk? Okay, cool. How many of you have used GraphQL? All right, that's awesome. And how many of you have encountered data API projects or data as a service initiatives inside your organization as well? Okay, cool. A handful. That's awesome. So the context for today's talk is I'm going to talk a little bit about the need for a data API. And then just given the audience here, depending on kind of what my polling resulted in, I would have zoomed in a little more onto the GraphQL side or a little more into GraphQL for data side. So I think given this, I'm going to zoom in a little more into the GraphQL side of things to give you folks an introduction to more of a deep dive introduction to GraphQL. So what I'd like at the end of the next kind of 25, 30 minutes is that you folks walk away with the idea of there's a seed in your mind of like, hmm, GraphQL is an interesting thing that I want to try out, especially in the context of a data API. So that's kind of my goal to kind of show you how GraphQL can be useful for especially data API kind of workloads, right? And then, of course, convince you to try GraphQL with your data and then talk about it. So just as a GraphQL evangelist. And then I'm also going to go over a few data mesh type architectures or data API type architectures that we've been seeing over the last few years with various users, various customers, both as a part of Hasura and then also broadly in the ecosystem as well. So that's kind of roughly my agenda for the next bit. Cool, so why do we need a data API? Data is everywhere. It's just exploding. It's insane, right? Like it just keeps increasing. It doesn't stop. It increases in volume. It's increasing in the types of data that we have, whether it's relational or transactional or graph or exposed by a SaaS service, search or time series. And it's also increasing in the workloads and the use cases that we have is also blowing up. So across all of these three dimensions, like volume type and use case, right? We're doing more with data as well. And as we start to do a lot more with data, it's great that we can kind of operate data, but unless somebody can use that data for doing something with it, you can take it to your users, you can give it to a different developer, you can take it, you can ship that data outside the organization to a different team, it's not useful. It's great that you've gotten the data and you've done stuff with it. But now you need to ship it somewhere, right? Or deliver it somewhere. And that's kind of where the need of an API comes in. That's going to be kind of where I'm going to be zooming in on, right? I'm not going to be zooming in on kind of these data systems that you have, the ones that you've had for the last 30 years, and the ones that you will increasingly have over the coming decade, right? It's just exploding, every month there's a new database as a service, right? Which is cool. And so I'm going to be talking a little bit about kind of that data API piece. And what we need from the data API and positioning GraphQL in the context of that data API, right? And what that really means. So, and again, the reason why a data API is useful is because it becomes, it's the kind of bottleneck or the gatekeeper to being able to use that data in contexts that are not just inside the data domain, but outside the data domain as well, right? So when we kind of think about, and I talked about kind of what we want from an API, right? When we think about an API that's specifically for data, right? A data API. Apart from kind of performance and security kind of concerns, you want to make sure that you're going to be able to continually evolve your API as well with the way your data is evolving, right? And that becomes a bottleneck, especially if you have a lot of data. Because you have hundreds of models, you have thousands of models. You're given a database or two databases or ten databases and each of them have hundreds of thousands of models. You don't feel like building APIs for each of them and for each permutation and combination of what shape people would want that data in, right? It just feels like work that we should not be doing. And that kind of is the context of introducing a data API and specifically with GraphQL. So, fairly obvious stuff when you think about what you want from an API. And one of the lenses that I'd like you to kind of keep in mind as you think about this is, just flip between two hats, right? The first hat is the hat of somebody who has to build this data API, right? You have lots of data, you're going to have to build a data API, Node.js, Spring Boot, Golang, whatever you're using. You're building an API that's connecting to these various systems and delivering that API. So you're wearing that hat of an API builder and you're thinking about your life and your day to day as you're building those many APIs. And then you're also wearing the hat of the API client when you're thinking about what is a nice experience and what is a good way to consume these data APIs and what kinds of challenges you'll run into as you think about consuming that API, right? So, flip between those two hats, that's kind of where we'll be looking at things from. So, the first, I'll dive into GraphQL. And I'm going to talk about GraphQL mostly through like a live demo so that you can see the API, that's the easiest way to understand it as opposed to going over kind of like a spec. So, we'll do that. But I wanted to highlight a few features and then we'll go into a demo and then we kind of anchor those specific features in the context of that API builder hat and the API user hat, right? So, one of the first features of GraphQL that makes it very useful for a data API, right? Is that it kind of better reflects the reality of the fact that your data and the models that you have in your data, they're kind of a semantic graph, right? That's just the reality of the way our data is. Data is related, that's why it's useful. And often when we are building these APIs, we don't very accurately capture the fact that data is related and it has in different sources, maybe even within the same source, but data is related, right? We end up building APIs that are kind of like points, right? We try to force fit the way that we think about data into specific resource endpoints that we can operate on. But the reality is that it might not, it's hard to think of things as independent resources, right? They're all kind of dependent resources. And so that results in two types of challenges, right? The first is when you think about API discovery, right? From the point of view of a user, looking at one particular resource is not interesting. I'd rather kind of look at things as they're connected to each other, right? That helps me discover what the overall API system is much. It's much easier to kind of consume that, right? But second also, practically from using that API, because everything is connected, you're often not requesting for a single resource. You're often going to be requesting for multiple resources at the same time, like you want a user and you want their top five accounts, right? The number of times you query only a user is vanishingly small, because everything is interconnected, right? And so practically what this means for an API user is that they're making multiple API calls to do anything. And that is the reality of systems much more than the reality of a single resource that you're fetching, right? So that's kind of one important capability of GraphQL that makes it useful, which it shortens that discovery loop and it condenses the multiple API calls problem into a single API call. And we'll take a look at what that is. The second thing that makes GraphQL nice is that its GraphQL specification can run on anything, but the de facto kind of standard is over HTTP. And it's very native to JSON. So it's very shamelessly JSON-first, you'll see that it's not as powerful, as say a SQL, for example, as something like Cypher, which is like a query language optimized for graph databases, right? But it's very shamelessly all about the JSON, right? And that's nice because most of the API clients want to consume stuff in JSON, right, more often than not. And of course, you end up spending a lot of time as an API builder, essentially converting things from where they are into JSON. That's a bulk of your precious life hours are wasted in doing serialization and deserialization, right? The third thing that makes GraphQL nice, which we'll also take a look at, is that it's a query language for APIs more than a set of endpoints. So it's closer to a SQL for your APIs rather than a collection of endpoints, right? And that makes it very nice because you can create your own conventions and you can create a flexible API that does things like paginations and aggregations and joins and cursor-based sorting and all kinds of interesting shenanigans that you want to do with your API and provide that capability. But in a more coherent query language type structure, rather than creating a new query param with the name that you felt like that particular morning, right? You're like, this should be called limit or this should be called first or whatever, right? So instead of kind of getting into that mess of what query parameters I should use and how I should name things, you can approach that entire problem of creating a flexible API a little more coherently, right? That's kind of what the specification allows for. The other nice thing about GraphQL is that it has modern primitives, like subscriptions which allow for consuming real-time data, consuming events and for consuming streams of data, which is also really nice because increasingly a lot of our data, well, it's not like 90% of our data is streaming data, but it used to be maybe a percent, now it's a 5%, right? These are random numbers, don't quote me on this. But the amount of data in flight and just the amount of data that we have that we want to send over an API, those volumes are going up and the data in flight, the amount of data in flight is also higher. Which now means that you'd rather have an API specification protocol that can handle those kinds of workloads as well as and when they come up, right? Cool. The last piece, which is one of the most important things that makes a lot of what I talked about possible is that the specification of a GraphQL API, the GraphQL schema, is a built-in artifact. For those of you familiar from the database world, when you think about creating a table inside a relational database, right? The database is introspectable and there's a catalog as an act of using the database. So in a way, your data models and the description of what your data is, is built into the process of using that database and creating models in the database. GraphQL is very similar in that when you create the GraphQL API, when you create a GraphQL server as a byproduct of that creation, you are fundamentally creating and putting out a GraphQL schema. The GraphQL schema describes the graph of all of your models, what operations are possible, how things are related to each other, what the types are. This has a massive impact on API documentation and on onboarding tooling, right? Just to go over all of this with examples where we can see this slide. Wearing the hat of both the API builder and the API consumer, think about API documentation or the lack of API documentation, right? The only thing more painful than building 100 APIs is documenting those 100 APIs and then continuously keeping up with that documentation. Somebody expected JSON true, but they got a capital TRUE because you were using a weird Python serialization library that just output a string instead of JSON because somebody screwed up, right? And maybe this change happened and then broke a bunch of applications and now you're sharing Excel sheets that have documentation in it because who wants to set up an open API spec, right? So it's not fun. This is not useful work when it comes to that API documentation. But when you think about API onboarding as well, when I'm using the API, the fact that when I'm using a GraphQL API, there is a schema there makes it very easy for people, for example, when they're building mobile applications, to have a typed SDK, right? So any GraphQL service, you can generate an SDK. You can get autocomplete on your APIs because the entire API schema is documented automatically. So it just opens up and the community goes crazy in building all kinds of tools that makes it easier for API clients, which is why when you hear about GraphQL, you'll often hear of it from the API consumers point of view because API clients really like the experience of consuming GraphQL. We'll take a look at that and it makes it really easy. The people who are building APIs, they don't like GraphQL as much because it's a fair amount of effort to build a GraphQL server, just like it is to build any other server that has a new protocol, right? So most of the love that you see for GraphQL comes from the API consumers because their experience is just absolutely amazing. All right, so with that, let's take a look at what a GraphQL API looks like over the next, say, five to 10 minutes. I'll take you over just a little bit of comparison of versus a rest-age API, like just putting them side by side and seeing what that looks like. Take a look at models and relationships. We'll take a look at querying. We'll take a look at a particular way to approach authorization, which is unique to Hasura, but it applies no matter what you do. We'll take a look at aggregations and how you can bake in more composition and how you can approach creating your own kind of composition semantics when you're building with a GraphQL API. We'll take a look at a few real-time examples and we'll see the benefits of schemas and types throughout these various examples. So with that, let me dive in straight into a demo set up that I have here. All right, so, cool. All right, so I have a GraphQL server that's running here. No matter who builds a GraphQL server in this particular demo, I'm using Hasura to create the GraphQL server for us, but that doesn't matter as whoever creates a GraphQL server, whether a developer creates it for you, whether you're using GitHub's GraphQL API, whether you're standing one up with Hasura, you're building one yourself with Java, it doesn't matter. At the end of it, what you'll have is a GraphQL endpoint. So what you see here is a GraphQL endpoint. Oh, sorry, do you want me to zoom that up? One more, okay, cool. All right, hopefully the UI won't break terribly. All right, so that is the GraphQL endpoint, right? That is similar to a REST endpoint that you would have had. It's just HTTP. When we send API calls to this endpoint, we'll be sending API calls over post, only post. And that's the nature of GraphQL. And you'll see that there's only one endpoint which is slash GraphQL. So there's only the slash GraphQL endpoint. Let's take a quick look at what the API experience looks like. So I'm gonna type in query. I have a model called artist. You'll notice this autocomplete kind of situation happening here. And then I want to see what attributes an artist has. So I'm just gonna control space and see what fields I have available here. So I have ID and name, and then let's run this. All right, so what you're seeing here is this is the API call that I made. And that is the response that I'm getting here, right? Let me scroll down a bit, all right. So that's the ID and name that I'm getting here, right? This is equivalent to something like REST API endpoint that would have done a get of slash artists. Right, that's what it's equivalent to. Instead of making a get request to a slash artist endpoint and getting a bunch of artists, I have a music artist API. Instead of doing that, what I'm doing is I am sending this query that text here to that post endpoint. And that's giving me the result which is in JSON, right? So the output is exactly what you would expect from a REST API as well. The, this language that you see here, the syntax that you see here, this is GraphQL, right? And if you look at it, it's pretty straightforward, which is why people like it, right? It's like the JSON that you want, but with the values removed, and you just see the keys. That's why people like GraphQL, because it's like, ah, that's what I want. If I can just remove the crap around it and just get GraphQL, right? And just get the data that I want. So that's what a GraphQL query looks like. That syntax is GraphQL. Let's take a quick look at what this API looks like. So if I want just ID and I run this query, I get just ID, right? If I add in the field name, I get it with ID and name, right? If depending on other fields that I have, so for example, I have albums and then I can traverse albums inside that and we'll take a look at album has title and the album has music tracks and stuff like that. We'll take a look at that in a second. But I can choose what fields I want, right? Now this is very useful from an API customers, from an API client's point of view and from the API builder's point of view, because if you have a model that has 100 attributes, you don't want to create unique endpoints for each particular shape of data. That is not useful work, right? Like just because the mobile client wants 10 attributes and the desktop clients wants 100 attributes, but there's a microservice client that wants like the 100 attributes and related data, you don't want to create unique API endpoints to service each kind of workload, right? This is now a built-in property of a GraphQL API that I can choose what attributes I want to get in the data that I'm in the response that I'm receiving. Let's take another look at kind of how parameters work. So I can now say limit that to just 10. So now instead of getting 300 or so, I'm getting just the 10, let's limit that to five and I'm getting just five here. This is kind of equivalent to a get endpoint that had something like a limit, right? Like a query parameter. That's, you're seeing that the parameterization kind of stuff is coming in here. That's where this goes in, right? And again, just to get a sense for what's happening underneath it, it's really straightforward. This is being sent as a post payload to this post endpoint. So it's literally a JSON object that is being sent that contains this query, the GraphQL server processes this query and then returns the right response. The GraphQL server figures out how to extract, there's a limit thing here, five, return only five responses. Exactly what a server would have done when it would have parsed an HTTP URL with query parameters. Same kind of parsing logic, but it's parsing on GraphQL instead of parsing a URL string with query patterns, et cetera, right? So just a different kind of specification there. Let's take a look at kind of what other operations we can do here and what this looks like. So there's this tool that I'm using, by the way, this tool called Graphical. This was also a tool that was open sourced by Facebook at the same time that the GraphQL specification was open sourced. This, the graphical tool, the reason why this autocomplete works, let's say for example I do NMAE and I try to run this API call, I get a error saying that the field NMA is not found in this type, right? So there's kind of this validation happening of what attributes I have available. I in fact see this nice little red underline that tells me you don't have NMAE, do you mean NAME? Is it like the AI in your API essentially? So that you're not making these kind of dumb stupid mistakes having to read documentation to see what the exact field name is, right? And this is IDNName, this is pretty straightforward. I'm sure all of you have seen various combinations of names that look very similar, that have a double T or a double L or a single L or all of those attributes that are Java like names, right, where you can have a lot of errors, right? So that experience is easy. Now the reason why this works is because what is actually happening underneath it is graphical, this UI tool, right? And you'll see this in Postman, you'll see this in any kind of API client that you're using that supports GraphQL. What these tools are doing is they're hitting this GraphQL endpoint and saying, tell me the schema that you have, like show us the GraphQL schema that you have. Just go opening up a visualization of this GraphQL schema, right? This is the entire API, right? And you can kind of visualize it. You would probably not end up doing this in practice too much, right? And this is like for like 10 models, right? For all of the permutations and combinations that you can have there, imagine if you had thousands, right? But here you can kind of see what your different fields are, what you can query for, what is related to what, right? But this experience is kind of automated when it comes to this graphical portion, right? So for example, when I look at my API, I'm like, hmm, what fields do I have? Oh, I have artists, that's cool. What can I parametrize on? There's a limit thing that I can parametrize on, that's nice. And let's see what I want to fetch, ID and name, that's cool, let's fetch ID and name. And then I want to filter. So let's say where name starts with A, right? And so now I'm only going to get the is, let's make it a little more interesting and get the j's. And so you see name starting with j, right? So you're kind of browsing this API and getting a feel for what the API is as through this kind of explorer experience, because it's zoomed in, it's cutting out and stuff like that, but once it's not, it'll be a slightly better experience as well. So you can see the different operators that you have, right? So because you see also, notice that everything is typed, right? So because it's a name, I get to do these kind of like regex type operations, right? But if it was an ID, because it's a numeric type, I'm only going to see operators that help me filter based on number kind of operations, right? Now, so for example, I can say where ID is greater than 67, right? And so I'm kind of browsing this API and learning about the API as a part of like using this API itself, which is a fairly convenient experience, right? All right, now just one important thing to point out here is the syntax that you see there of limiting and where and offset and whatnot, that is entirely in the control of whatever GraphQL service you're building. So if you're building a GraphQL service where you want to provide advanced filtering, go for it. If you don't, don't. In Hasura's case, our aim is to provide that kind of flexible filtering thing so you see lots of filtering options. All right, cool. Let's take a look at the graph in GraphQL. So this setup that I have here is an interesting setup where I've taken three different data sources. I have a BigQuery data source, a Postgres data source, and a SQL server data source. And what I've done is that in my Postgres data source, I have artists and these are the artists that we've been looking at. And what I've done is I've taken the albums, like each artist has a bunch of albums and I've put that in SQL server, right? Just because. And so the albums are kind of here, right? What I've done is I've created a relationship between these two models. The artist model has a relationship to the album model through an artist ID, right? And because I've created that relationship, we can kind of see that in the GraphQL API, right? So let's see, let's limit that. Let's remove the where clause and let's fetch albums that have a title, right? So now what you're seeing here is the artist, right? And their albums, right? And you're seeing that in kind of the, again, you're seeing that in the format that you'd expect to see it in, in the shape of the JSON that you want to see it in, right? So as you kind of start connecting this kind of semantic graph of the various models that you have, your API customers can start querying that for the right shape that they want, right? For all of the attributes for join things and whatnot. And then again, just to make this interesting, I put all of the music tracks in a different system. So the music track has name and maybe like the amount of time it takes the tracks to run. So each album now is fetching multiple tracks and you're getting multiple tracks from wherever it is, right? So this kind of makes that experience of consuming the data API, of discovering what I have in the API fairly easy. At any point of time, I can go in and kind of look at the documentation for what the pipes are. So for example, and I'm gonna zoom this up again in a second. If I look at album, and I just zoom this up here, you'll see that the album has a title, which is a string. It has an array of track objects, right? And the track has bytes and milliseconds and media type and whatnot, right? So this property of the documentation, this property of what is browsable is all kind of available inside the, as a part as a free artifact of using GraphQL itself. So that's a quick look at what the GraphQL API looks like and kind of why the experience of consuming GraphQL, especially for a data API, is far richer and far more convenient, both for the builder and both for the user. Well, when I say builder, be careful because somebody has to build the GraphQL server. So that part is a little bit tedious, but assuming you've gone through that process, a bunch of this stuff becomes really easy, right? So that's a quick look at GraphQL before I kind of zoom into some ways of composing permissions and aggregations, which are interesting, which is just to show an example of how you can compose stuff together. I was going to say before I move on to that, if folks had any quick questions on the kind of GraphQL things that they wanna see, but we're running a little bit out of time, so we'll save that for the end. All right, let's take a quick look at what aggregations could look like, right? So aggregations are cumbersome to put into a data API. It's not very natural, especially in a JSON style API, right? And so I'm gonna describe one approach to thinking about aggregations when it comes to from a GraphQL API point of view, right? So if the kind of convention that we've started following, right, is that every time there is a list of resources that we're returning, we'll also provide an aggregate for a list. So any list gets an aggregate. So like for example, we had artists, right? And you look at these artists and I have like whatever a few hundred of them. This is a list. So any list gets an aggregate. So if you think about that, what you'll also notice in your API is the ability to run, is to convert that into an aggregate and then you can do a thing like count for example, right, and then you'll get a count. But the nice thing is that these can compose across relationships in your graph, right? In your API. So for example, you can do query artists. Just to make this a little more sane, let's limit that to 10. And if you look at artists having albums, right? Each artist has a list of albums, right? So for example, ACDC has like two, except has two and Aerosmith has one or whatever, right? Because there's a list that's a nested object, I can also convert this to an aggregate, right? Now this is a particular convention that we follow as when we generate a GraphQL API. But the idea here is that you can create kind of a convention or semantics for your data API that compose well together, right? And so here for example, I can now say artists with an album's aggregate and that aggregate is a count of two. So this kind of fits in a little bit naturally into a JSON API graph kind of structure. And at the same time allows you to think about how you wanna introduce aggregations in your API. If I were to kind of abstract this up one level and think about what the overall concept is, the concept is that a group by, right, is the top of the graph. So the group by key comes on the top. So the group by key here is an artist. So group by key comes on the top and then the aggregation operations for the list is nested inside that GraphQL structure. So this is one way that you can start composing aggregations into your GraphQL API as well and offer a fair amount of flexibility to the API customer as well to say, oh, cool, I wanna do aggregations on a list, a sensible thing to attempt to do. And now I can run those aggregations and they'll compose across relationships as well, right? And this is interesting. And there's an interesting amount of work that we've done here at Hasura to make sure that this is actually composing across two data sources. So you're seeing that this aggregation is running across Postgres, data source and one and SQL Server on two, right? And you can imagine the kind of database in Anagans this takes to get it to work, but that aside, what is interesting here is that you can kind of get this composition and a neat API that makes sense and that is extensible kind of working for you. We'll take a quick look at what real-time APIs look like before we switch into what different data API architectures look like. So, all right, let's take a look at subscriptions which is always a fun thing to look at. So I've set up another toy kind of application here where I'm gonna sub query color info, right? So I'm running this query and I get a description saying green, plants reflect only green light, red has the longest wavelength, plants reflecting only green light was a bit of a mind-blowing thing as a child to learn. But, right, that's why they're green. So anyway, that's, so I'm just running a simple straightforward query, right? What I can do is I can convert this to a subscription and now I'm getting this data but now this is real-time. So if I go and imagine that the underlying data source, let me just split these into two tabs here, right? Okay, so you're seeing that this is a response here, right? If something now happens to the underlying data source and says plants reflect only green light and occasionally purple, right? As soon as I make that shift here, you'll see that this kind of gets updated as well, right? And this is just a very neat and obvious abstraction for an API customer because they're like, yeah, this is the model that I'm interested in and now just subscribe to it. So whenever it changes, you get changes, right? So from an experience point of view and from an API point of view, as you start kind of subscribing to entities in your upstream data sources that are changing, you now have a way to think about how you want to expose that to your customers and again with the same benefits of GraphQL, right? You're getting to parametrize, you're getting to authorize, you're getting to choose what attributes you want to send over but it's quote-unquote real-time. You can extend this idea to streams as well. So let's take a look at, I have a stream of colors and let's see how many fields I actually have. Let's look at subscription, color stream. Let's stream in batches of 10. What is our initial value here? Okay, let's start off with an initial value of 5,000. And so I have like a, I think 100 million elements or records in this color's model, right? And let's fetch ID and color, right? All right, so what you're seeing here is that this has now become a stream where I'm kind of doing almost like a bulk data extract operation over as many records as this is with this idea of an offset or a cursor, right? The client in this case now says that I'm not interested in a value of a single element that's changing but because you have this massive list of elements help me stream through that list, right? And give me access to what you want. And so this is another kind of convention that you can add on to a graphical subscription to expose kind of the semantics that you want for your API, right? And this again is nice because increasingly you're gonna have data workloads where people want to ship like massive chunks of data. You want authorization, you want the same control of what payload should be. I wanna stream not the 100 attributes but just five. All of those things and you want to send that across to people without like emailing them or FTPing them like a file or whatever it is, right? That I've never done thankfully. But that some people have done. So that's kind of what a subscription, a stream might look like when you think about a streaming API. So, okay, that's a quick look at what the GraphQL API looks like. And we covered a bunch of these. I'm gonna quickly zoom into a few different data API architectures before we pause for questions. So I think examples of three types of architectures that we've seen with users in the way people think about a data API, right? So the first is kind of like a operational data layer or hot data layer kind of system where what folks do is they think of, they have data in various sources. They EPL that to a central store, kind of like a data warehouse. Depending on the nature of your data, it might be a data warehouse or it's more operational. Where you keep that data, you stick a data API in front of it. For example, you build your own data API and then that becomes the API that you're giving off to your clients. Here, when I think about these architectures, for me, it's always interesting to think about like ownership and agency, right? So here, the persistence layer is owned by the team that also owns this data API. This is interesting because you get more control of things like performance. It sucks because somebody has to build all of the ETL stuff to come into this ODL layer, which is depending on how much of a budget you have and who's keen on doing what, that may or may not be an excessive one undertake. But that API team still controls the API experience, right? So that's kind of what this looks like. The dotted box that you see here is the ownership box. Another example that we've seen is where you just have the centralized data API layer, but you have various different data sources. I've called them databases, but those could be databases, those could be REST APIs, those could be GraphQL APIs, could be GRPC, could be whatever. But you're creating the same semantic model across these data sources. And the team that owns the data API only owns the data API layer, which is stateless, has maybe a caching layer with it. You're centralizing your authorization governance and you're centralizing the API experience, but because you don't control the persistence layer, performance sometimes becomes hard to guarantee and hard to control. Right. The third, which is kind of a variation, is the more federated setup. And this kind of starts resembling more of the data mesh type things that people are gradually moving towards. The idea here is that you have various data products. So DB1, for example, is owned by a different team, DB2 is owned by a different team, DB3 is owned by a different team, and DB again is a data source here. And the consumer owns the data API experience that is then connected to these sources. So it's kind of the authorization is split, that the authorization governance is split or federated or split and federated across these two, right? So the data product owners control kind of slightly less granular governance for their data product. But the specific API consumers, they own the API experience and the finer grained kind of authorization entitlements that decide who gets to extract what data or use what data in the data API. The compute infrastructure is also split because you're running some queries against the data products itself, but you're also running some of that compute as a consumer, you're owning that kind of yourself, right? So this is also kind of a more federated architecture that we're starting to see, especially in conjunction with things like a data lake kind of idea, right? Where you chop things into object storage, you have like an Athena-like layer on top of that, and then you start building your data APIs in front of it, right? So that different consumers own. So those are kind of three variations that we've seen that have different kind of pros and cons. Bram, wanna call it time. We'll share the link to the slides as well, so all of these are links, but there's a few interesting things here to look at. One of them is kind of the underlying architecture or approaching building a GraphQL server as a compiler or a transpiler, as opposed to building it as a traditional API server. The second is an architectural deep dive and discussions on various approaches to build real-time subscriptions and to build streaming, what the different pros and cons are and how you think about building and scaling out such systems. What I would love to hear from you is, try GraphQL, try it out with your data. There's a link here that in this particular case for the demo that I use, that uses Hasura needs a doc container as well, but if you get to try it out yourself, would love to hear what your experiences are like. Feel free to reach out to me at Tanagon Twitter or on LinkedIn for any questions or discussions about GraphQL or data and stuff like that. Also as a plug, would love to announce our annual user conference, a free and open user conference with contributors and people collaborating on the Hasura GraphQL engine, different announcements and things that we're doing, that that's happening next week, where we'll be talking about this is live stream, right? Okay, I can't let the cat out of the bag. But interesting things for people to build support for as many data sources as they have, everything from DB2 to Airtable, and then kind of get that same GraphQL experience. So we'll be talking about a whole bunch of things next week as well, so do join us for that, again, free and open conference. But that is my time, and if you folks have any questions, I can take questions. So I think we have a little bit of time if you want any live demo type questions as well. Yes, go ahead. Yep. No, you have to, no, it isn't. The kind of streaming that I demoed, nobody's, like, that's not an out-of-the-box thing anywhere else, I think we're the first people of kind of approach to this way. The reason why it's hard slash interesting is because it needs a fair amount of integration with the type of data source that you have, right? Because you wanna, when you're doing us, when you're providing streaming on top of Postgres or on top of Kafka, on top of Cassandra, on top of different types of data sources, the ways that you'd want to optimize that is a little bit different. So we do that through a deeper integration. That's what it takes. Which we did, can you do right? Yes, they're called mutations. So the GraphQL keyword for that is mutation. And just to show you what that looks like. Just like we have a keyword called query and subscriptions, we have a keyword called mutation. And for example, with Hasura, we generate a bunch of mutations for correct actions like insert, update, delete. So you'll see a whole bunch of different mutations that you can run. You can also map, like another way to do it is to think of, from a CQRS point of view, you'd think of a mutation as executing a command, right? So the mutation essentially fires a command. The command goes and does a bunch of stuff and updates the read models. And then the response of the mutation returns the read model. So just to show you what that looks like, if I do create artist, I pass in the payload. And then when I return that response, right? I can traverse the entire ID, like the artist model. So this is the read model that you're seeing here, right? This is like the GraphQL system is hitting, like assume there's a read after write kind of situation that happens, right? So the create artist that sends in like, I think it'll take an email and a name or whatever, right? So this is like a custom command. There's a piece of business logic that'll go and run, that'll take name and email and do something. And once it does a thing, it returns an ID. The GraphQL system enriches it and returns and understands this ID is actually a reference to the artist model and then provides this ability to traverse the entire artist model. So that becomes another way of approaching mutations. So, but at a GraphQL specification level, it's called a mutation. The GraphQL spec wisely does not bother too much with verbs like post, put, patch, delete because they're like, man, it's so weird. You'll do whatever you do with the right operation anyway. Just call it a mutation and go. That's the idea. And then what, it's your convention on how you wanna create mutations, right? You had a question? Yes. Yeah, yeah, yeah. It's not a part of the GraphQL specification by default, but you can layer that in as kind of a convention when if you're building out a GraphQL service. What we do, for example, is we associate a execution cost with every GraphQL query. And that execution cost maps to essentially the time that it takes to execute a query. And then different API clients can get like a cost quota. So you can create roles or sessions and say that this person has a cost quota of like 500 milliseconds to the minute, right? So you get to execute your API calls for a 500 millisecond window net in the span of a minute. So you can run one API call that's 500 milliseconds long. You can run 10 or 50 milliseconds long within the span of a minute and then you get rate limited. So that ends up being a nice data API experience. There are lots of other kind of ways that you can denote cost, but I think from our experience it's not as practical. Like you can have cost based on like how many joins are you doing, right? Like how many attributes are you fetching? Or what is the query complexity? But those are so vague because sometimes you might have a really simple query, but the data volume is so large that analysis of the query complexity doesn't help because when you juxtapose it with a real world like amount of data you have, the cost is out of the window, right? So it becomes more sensible to just think of it as a quota. That's one way of doing it. So everything I talked about is open source here both in the project that we've made plus the GraphQL specification itself. The GraphQL specification is pretty light. It has queries, mutations, and subscriptions, right? And then it says that inside the query, inside the mutation and inside the subscription, what you want to do is up to you, right? So for example, the conventions that I showed around limit offset where, right? That's a convention that is unique to Hasura, right? If you were building your own GraphQL service, you would have had a very similar looking GraphQL query that queries users, but maybe you don't like using the word limit offset. Maybe you would have used the word first last. You would have used the word page instead of offset. So that convention of the particular words that you use, the nouns and the verbs that you're using to describe operations on your API, that's unique to you. The overall structure of having queries and mutations and subscriptions and that format that you saw of like the JSON style format and the parenthesis, that is a part of the GraphQL specification, right? And then there's a bunch of other stuff also around fragments and whatnot, you don't have to get into that, but that's the GraphQL spec and then whoever is implementing the GraphQL spec might have their own conventions in how they think about the GraphQL API. But everything I talked about is open source, by the way. Proprietary in the sense that it's unique to this product, but yeah, yeah, yeah, yeah. So as from a Hasura point of view, the way that we approach it is, so we have a UI like a, that helps you kind of create models, set up relationships across models and stuff like that. So you're kind of creating these relationships and you're creating authorization rules and whatnot. The way Hasura works is, it's not GraphQL schema first, it's metadata first. So you describe your metadata's domain, like you describe your domain via metadata. So you say that I have an album model, an artist model and they're related, right? And then Hasura uses that metadata to create the GraphQL schema. So you don't create the GraphQL schema, you describe the metadata, Hasura creates the GraphQL schema. But there are many different approaches in the way that you could create a GraphQL API. You could go schema first, where you first describe the entire GraphQL schema and then you start backing that up with specific operations, right? That's schema first. You could go, what we're doing is like metadata first or model first. You could even go code first, which is kind of this, you imagine that you're writing these Java controllers and as you write these Java controllers, the schema is spit out automatically, right? So there's many different approaches that you can take. The approach that we take is metadata first. All right folks. Oh, sorry, any questions from the stream? That's a good question. Can this be used in embedded environments for distributed databases? I'm not sure what the question means. I'm gonna unpack that in two levels. Can you use this in embedded environments, like an IoT environment? Yes, you can. It's as long as you can run a Docker container. So you can run a Docker container there. That becomes your GraphQL server. You can run that there. You can run Hasura next to a distributed database as well. And as a part of the Hasura metadata, you'll add annotations to describe what your chart, like what your topologies, and then Hasura will do the query routing appropriately, for example. So we support distributed databases as well. We do Yugabyte, Citus, Cockroaches in like early preview. We do Cockroaches as well on the Postgres side, and then a bunch of other on the non-Postgres side too. So yes, I guess is the answer to that. All right, thank you so much folks for the questions and for spending time here. And I'll be around.