 Thank you, Candace. Thanks for recording your progress. Thanks, everyone, for joining. As Candace said, my name is David Benimiglia, and I'm presenting on, not only the title for this is Cloud-Native Data Access, but my ulterior motive is to try to persuade folks to consider writing less code and to talk about or show ways to do that. By way of introduction, we already covered some of this. I'm a customer success engineer at Hasura, a software technology company that provides developer-focused tooling products. And so this talk is an aphorism-driven talk, wherein I motivated reasoning and confirmation bias to seek out some famous and not so famous people and pity sayings to support my point of view and to try to put God on you into believing what I'm saying. And some of those sayings are mine. And one of the, something that I often say is I believe that the best code is code that you don't have to write. OK, so what are we going to be talking about? Well, one of the things that we will be talking about is Hasura, the company that I work for and the products that we offer. So what is Hasura? Well, on the tin, we say, one of the things that we say about our product is, from your databases to unified GraphQL API in just one minute, what does that mean? Well, that's the marketing copy. What does that mean? Folks who don't know, a brief primer on GraphQL. GraphQL is a query language for web interchange. It is a successor to, and in some cases, a replacement for REST-based APIs, although it rates with and some of the operates over REST. It is, it was invented at Facebook who created a specification for it that has a spec. It is defined by, there are schemas within schemas. There are types, types are collections of fields, and types can relate to each other. On the right, this is just a simple depiction of what a GraphQL interaction might look like. You express a query on the left wherein you specify what data you need from back end, say. And then on the right, you get a JSON document that represents those data. And if this sounds at all familiar, it should. It is not all that dissimilar from SQL. SQL has schema, SQL has tables, not types, and it has columns, not attributes, but you can map those one to one. And in many ways, GraphQL and SQL are isomorphic to each other. Many GraphQL queries can be, if your back end is supplying data from a relational database, which is often the case, GraphQL APIs and GraphQL queries can be translated into SQL queries. And spoiler alert, that's what Hasura does. Hasura is a, in just one minute, you point your Hasura instance, this is an image of the GraphQL user interface for Hasura, which I'll be demoing later, but you just provide your connection information for your database. It stands between clients and your database back end. This is just a simple depiction here. It is essentially, it's a web server. It is a web server and it's a database client, but it will introspect your database for the tables and the views that you have within it. It will present those as GraphQL types and it will translate GraphQL queries into SQL queries and then mediate that information and provide that information back to clients. Clients being things like mobile clients, web application, things of that nature. So why are we talking about this and why is Hasura doing this? There are a lot of ways to think about this. One approach that I'll take if you'll indulge me is a bit of history, a stroll on memory lane. So who remembers two-tier architectures? This would be, as I remember it, these dates are sort of nominal. The late 80s through the mid 90s, there were two-tier architectures or client server architectures where typically there would be a, what we call a thick client written in visual basic or power builder talking to a server on the back end. Often that server was a SQL database and there would be, the business logic that you would have would be either in the database, but also there was a lot of business logic in the client, in the client front end. But we moved on from that. We went from two tiers, two tiers to get another tier. We had three-tier architectures. We're getting into the late 90s. Now we added an application tier in the middle. The presentation, this is the beginning of the web era. The presentation tier is now HTML web pages, maybe a little bit of JavaScript. So there's really no logic there. And so the business logic was placed in this middle tier written in, again, visual basic or Java or Perl or Python or what have you. And then things got more complicated from there. If three tiers is better than two tiers, then in tiers is infinitely better. So we got very complicated with, a lot of these things were worthwhile, but there were business logic servers, message buses, lots of caching and web location firewalls. And things just started to get more complicated. We moved on to service-oriented architecture. We're getting into the 2000s. And this is all worthwhile stuff that things were getting, again, quite complicated. And in this era, a lot of code was being written. Things started to, the sort of parabolic arc of complexity maybe tipped over in the 2010 era. We started getting microservices that started simplifying things. Restful APIs came in as a way to, as a model for standardizing my API backends and that helped simplify things. But there still was a lot of code, things were getting quite complicated. Containerization helped out Docker, even serverless functions, that helped out a lot. But we were still in an era where, we were writing code, we were writing code in Ruby, or we still are writing code in Ruby, Java, Python, JavaScript. But where things are started to simplify and Hasura is helping that out. And so an era that we're now in is sometimes considered a low-code era where we're able to get work done and make progress with tools that provide a lot of leverage and help us get our work done with less code. And that's where Hasura fits in. So Hasura, again, as I mentioned earlier, it sits in between your database, Postgres or Microsoft SQL Server or a few others. And your front-end written in React or Flutter or Next.js or what have you. And it mediates that exchange between the database back-end and the front-end with relatively little code. That's where we, this is where we are, maybe this is where we're going, the so-called no-code environment, where maybe we can even make progress without writing any code, right? There are tools like Airtable, if you've heard about that, which is a sort of a spreadsheet database hybrid. It's very easy to use, user-friendly. There are tools like Glide apps and Sheets to site where you can just point those tools directly at either Airtable or Google Sheets and you can get a mobile app with absolutely no code. And that'll be pretty great, but that's not where we're at yet. Where we are is here in the local environment with Hasura and relational databases. But so the question is, where or how, how are we actually going to do this? How are we going to use a tool like Hasura to achieve our ends and write relatively less code? Well, how we're going to do it is some good old-fashioned data modeling. So here's what we'll bring in some of these, you know, pithy aphorisms. If anybody wants to jump into the chat, who knows who said this? The language might give a clue of when it was said, show me your flow charts and conceal your tables and I shall continue to be mystified. Show me your tables and I won't usually need your flow charts. They'll be obvious. Well, this was Fred Brooks in the Mythical Manman, which is a classic of the genre. Fred Brooks was a computer engineer in the 60s and 70s, project manager for the IBM 360. But the principle here is that is one of the principles is that data modeling is of immense importance. And if you build applications centered around the idea of data modeling, then the actual procedures, the code that you write will be in many ways less important. Here's another pithy aphorism. This will, the reason for bringing this in will be evident maybe a little bit later. Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified bug and slow implementation of half of common list. Why do I bring this in? First of all, who said this? This is Philip Greenspun, who was a prolific author and educator and computer scientist, still is. It was very active in the 2000s. Was it one of the co-founders of Ars Digida? Here he is with his dog. But the reason I, so a saying that I often make, I adapt this saying in the following way, any sufficiently complicated Java or Python program contains an ad hoc, informally specified bug written slow implementation of half of the relational database. Because another thing that I often said, well, okay, here's another quote from maybe a slightly less famous person. What are you typically doing, or what are you actually doing when you use a typical web application? Well, this was asked of me by Ben Warronk here at Hasura the day he interviewed me. And his point was, if you're interacting with a typical web application, like let's say an online retail store, what you're really doing is you're interacting with a database. Databases are at the heart of our applications. And so the reason I say this is because here's a picture of Ben Warronk looking quite handsome. I often say, well, what are you actually doing when you write a typical program? Often I think when you write a typical program, what you're doing is you are building an ad hoc, poorly implemented bug written version of a relational database. So what I would say is, why don't you just use a database? I'll say this anytime anybody asks. Now, another, so this was said to me by a friend and colleague at Hasura just last week when we were talking about the subject, PLSQL isn't a real language, real programming language. Well, for those folks who don't know PLSQL, that's the procedural programming language for Oracle database, but really you could substitute any of the procedural languages for any of the databases. You could even substitute SQL. A lot of folks feel that SQL isn't a real programming language. And this was said by name with hell. But I break this, there's a bit of foreshadowing. This will be the reason for bringing this in with the evidence a little later. But as I said, in my view, often when we, what are we doing when we write a typical program? What we're doing is we are writing a database. So what are our typical data containers in Java, Perl, Python, what have you? And I choose the word containers for a specific reason. But what we usually, we have variables, obviously. We have arrays, we have lists, we have maps. But really, I mean, abstract, if you boil it down, what we really have are collections, collections of things. Even a single variable is a collection of one item. Of course, there are different data structures, there are queues and there are priority queues and there are FIFO buffers and ring buffers. But those are sort of specializations. They have different performance characteristics and different, slightly different behavior. But in general, what we're doing is we're working with collections of things. Well, what's a tool that is built around operating on collections of things, relational databases? Relational databases within a relational database, relations or tables are collections of things. So maybe we can just use that. Like I said, a typical, and so if we use a typical relational database, what do we get for it? What does it provide out of the box? We'll provide this a lot. It gives us efficient storage, over huge volumes of data, fast access, powerful and flexible indexes, joint operations so we can relate data to each other easily and flexibly without pointers, constraints for richly modeling our data and our application, flexible query language, overall of those aspects, access control, permission systems, a unified data model that is, by unified data model, I mean that everything within the database, including its own catalogs, are tables, a concurrency and other things that I'm sure I've lessened things off the list here. So if you're writing your application in code, if you're writing it in Java and Python and you are throwing around lists and maps and iterating through those and finding elements within them and performing filtering operations, you're sort of performing a lot of the operations that you would perform in a database, but you're not getting all of these benefits. If you were to get all of these benefits, you would have to write a lot of the code, all the code associated with this. So getting back to the title of this talk, how do you write less code? You use a database, use the relation of database as it was intended and the features that are within it and you get a lot of code for free. So you have to write less yourself. But then of course, the subject of business logic will come up, where do you write your business logic? What is your business logic? And why didn't we do this before? Well, part of it is when we built web applications, web application, if it's fronting a database, it has to do at least two things. So one, it has to present the data from the database on the web. It's basically, it's a network server providing HTTP access and it's a location or it's a site for business logic. So we would write our business logic in Ruby on Rails or in Apache Tomcat and Surplus, but what would that business logic be? Well, if in a lot of cases, at least for online applications, it's really boils down to just a few simple things. There's input validation. The user has made a request to record some data and you have to verify like, is the requested valid or the data valid? Is the user have the necessary roles and permissions to perform this operation? These operations. Is, even if the data and the are correct and the user has the right roles, does the current state of the database, does the current context allow that operation to proceed? That's input validation. Data transformations, which is related is maybe more of a read operation where you have data and you are presenting them in some different way. You could be summarizing data into summary statistics, aggregates, you could be summarizing data into charts, graphs and visualizations. But again, that's another form of business logic. But I think thinking about these things in this way and paying attention to the fact that there are just a few simple categories of business logic. I think it clarifies things and helps us figure out how we might implement this in the database. And the third piece of business logic would be side effects. This might be where your application has to send an email or fulfill some product. But we can even boil this down further and say, well, typical business logic is really in, especially if it's a database backed application, it's a state machine. So for the state machine, there are some set of allowed states. There are allowed transitions from one state to another. It's just that in many database backed online applications, the number of possible states is too great to enumerate and the number of possible transition is too great to enumerate. But essentially it is a state machine. But so maybe one way to think about it is rather than states and transitions between them, we think of constraints. So what are the limits on properties of states that we could transition to? And the reason that's useful is it helps us map this over into database modeling and database constraints. Put even more simply, typical business logic in an online application is function evaluation over data. The function evaluation might be a Boolean predicate where you compute a Boolean over some volume of data to decide whether an operation or a transition is allowed. So really often it's function evaluation over data, but then there's a detail which is after finding the data. So again, this is what we would be doing in many applications that we would write where we would write the code in Java or Python or what have you. But we would have to do the work of not only the function evaluation, but finding the relevant data. But this is what relational databases are built for. So okay, well, so where the rubber beats the rubber how do we actually do this? Well, here's my patented advice presented in sort of the language of BotWorks' technology radar where they say adopt, hold and so forth. What I would say is do adopt declarative programming features within your database. So of course tables, but also use SQL views liberally to do those data transformations in your database. Use schema to organize your data model. Use data types liberally are the databases that we the sort of big four for databases, Postgres, MySQL, Microsoft SQL Server and Oracle give us a rich array of data types. And those data types themselves are they represent constraints. There are data types for all the usual suspects, ints, floats, text, but there are more exotic ones. There are data types for network addresses for geometric objects. And those come with constraints so that we can have some assurances that the right data are written into the right data types. And then besides that of course all these databases they also offer custom data types. In Postgres there are enumerations, there are range types, there are intervals. So I would say use those liberally. Use the permission systems within those databases. Again, a great deal I would say of business logic that we have is again making a judgment about whether operations can be performed. Is the user, is the operator allowed to perform this operation? Authorization. A lot of business logic comes down to authorization checks. The database is prepared to do that for us. Use constraints liberally. Primary key constraints, unique constraints, foreign keys and check constraints. When you can get pretty far with data types and custom data types but the thing, if there's anything else that you can't do and you can often do it with check constraints. Use row security policies and if a database offers that, at least two that I know of offer row level security. Postgres does and Microsoft SQL Server does. And what that means is the database has affordances within it where you can specify criteria for which users are allowed to access individual rows within a table. So, in an example, if you have an account table, you have all of the accounts in your service but a user should only, let's say, be able to access and see the row associated with their account. They should be able to see anyone else's. You could write the code to do that. You could write SQL code to say, check that the user's account ID matches some session variable. You could write that in your application code in Python or Java but at least a few databases allow you to set that declaratively and then the database will do it for you. Use default values on tables. That's pretty straightforward. I would say use assertions as well for those who don't know. So, check constraints allow you to, if you rose up, check constraints allow you to specify a set of properties that must obtain for the fields in a row in an individual table. Assertions allow you to express constraints that would apply across tables within the database. Unfortunately, even though assertions have been in the SQL spec since, I think, 1999, pretty much no database that I'm aware of implements them because they're hard to implement generally, but in particular case, you can fake them with triggers. So, if we use all of these features within the database, we can get pretty far in building, I believe, in building many of our applications. And all we've used to do that is, for the most part, is SQL. And as we talked about earlier, SQL is not a real programming language. So, again, evidently, we've gotten pretty far without writing any code. What I would say is hold on the procedural programming, i.e., stored procedures. So, when the subject of business logic in the database comes up, one objection often is, well, we don't want to have so many complicated stored procedures. Well, I would say, for those who don't know, many relational databases, Microsoft SQL Server, Oracle, Postgres at least, have functionality within them. So, you can actually write procedural code. You can stitch together a sequence of operations and SQL operations, package them up as a procedure, store them within the database, and then execute it as a procedure. And they're useful and they're worthwhile. Having worked in this field for a long time, I know that there once was a time at least where this was the first tool that people would reach for when writing business logic or code within the database. I would say this should be almost the last thing that you reach for. If you, if you, if we use these declarative aspects within the database liberally, then we will find there relatively few circumstances where we actually need servers. Okay, so I welcome questions and comments, but as those may blow in, I'm gonna set up a brief demo to illustrate how this might be done in Hasura. So this tab here, what you're seeing here is, so just a bit of background. So Hasura is, again, it is a HTTP server. It is also a database client. It's an open source project. So if you wanna deploy Hasura on your own infrastructure and self-host, you can absolutely do that. But as a company, we offer a Cloud Managed Project where we will run Hasura for you. And this is the console for Hasura Cloud. And we offer a free tier. It's pretty generous actually. It has some limitations, but they're relatively few. We will launch a new project in the free tier. Now, Hasura Cloud is bring your own database, meaning we don't host the database for you, but we do integrate with Peroku, which is another Cloud provider, to make it pretty easy to set up a simple Hasura instance and database. So I've created a project here. So this is a running instance of Hasura. The details, we don't need to dwell on this too much, but what we'll focus on is launching the console, which is the graphical user interface for managing Hasura. So this comes up. And so this console would be available to you whether you self-host Hasura on your own or whether, again, with you running within the cloud as we're doing here. Just orient you. There are a number of useful tabs across the top. Where we wanna go is, so this console application, if you're using Hasura, this is one of the places where one does a lot of your work. There's a where you do data modeling and this is where you integrate with Hasura. We will, as I said, Hasura Cloud integrates with Peroku, so it makes it easy to set up a hobby system. You just create a database here. And since I'm already logged into Peroku, this will reach out to Heroku, set up the database, establish the connection between the database and Hasura and we're almost off to the races. Just let that, that works. Oh, there we go, adding data source. So while that's happening, what I will do is, let's see, view database. Now, the way Hasura works is, or what we do is when this service connects to your database, it will introspect and discover all of the tables that are available and it will offer to track those. Tracking means exposing a table as a GraphQL type. This is a fresh database, a brand new database. There are no tables. Within Hasura, we could, Hasura console gives you the ability to create tables. You can do it right in here. You can also, of course, create your tables in SQL and whatever migration tool you like, but you can also do it right in this tool. But you can also just run SQL directly. So what I'm going to do is, if you want to flip over to, so this tab here, this is GitHub and this has all of the code for this talk. So this has the set of slides that you're just seeing and there is a SQL code that I set up to set up a model. And that's in here, in the model. You can see that it's a simple retail application. It creates tables. There's an account table, product table, orders. But you can also see that there's some business logic built in here. We have some triggers to manage an update timestamp on these tables. What else do we have? There is, there's a border table or the details. There's a function. There's more business logic. So again, we could write this in some other language, but why don't we write it right in the database? Function to search over products, do a text search. There are, there is a, ah, there's a constraint that we add. We say, well, let's set a constraint on product prices. Doesn't make sense the prices to be negative. So make sure that there can't be any negative prices. So again, you know, this is the kind of check that you could put in code, Java, Python, or you could just write it declaratively right in your database and then not have to worry about it. And there are a few other pieces as well, but what we'll do is we'll just say, do this as raw SQL, copy all of that. And then we will just put that right into our Assert instance. We'll just paste it right in here. That'll create all of those tables. So what Assert is doing, is just dispatching the SQL to the database. If I had opened up a CLI session or database connection to the database, I could just run it from here, put this from there, but this is, this is convenient. So let that bake for a few seconds and what do we got? What do we got? Okay, so Hasura has noticed that now there are these tables that account table order or the detail product region, couple of functions, and it's offering to track them. So tracking means that these will be exposed as API types. If we go over to the API tab in Assura, one of the features of GraphQL is that it offers introspection over the data model, which what that means is that GraphQL tools can introspect the GraphQL API and discover what types are available. There's some common functionality that's often provided. So for instance, documentation on what types are available would appear here. But we can see that there are no types that are available. That's because we're not tracking anything. So we go back to the data tab and we just say, let's track all of these tables. And once that is done, we said earlier also that GraphQL types can relate to other types. Well, that corresponds to primary foreign key relationships among tables. And so what Hasura has done here is it's noticed that in this data model, there are primary key foreign key relationships among these tables. And it's offering to set up relationships. It's offering to track those relationships for us as well. We don't have to, but we can. We say track all of these just to be quick. And once we do that, we go back to the API tab. Now, the Explorer tab in Hasura now shows us that we have all of these types. We have an account type. We have an order type. We could start to perform GraphQL queries on these. We also have documentation for all of these. In query root, there's, these are all of the types that are available. And again, these just correspond to those tables and database. So we got all of this without writing any code. Of course, we don't have any data yet. So why don't we fix that? So we'll go back over to our GitHub repo. And I've got some seed data in here as well. Data.sql, which just, as you can see, it inserts some ersatz names, some products. These are grocery products. And then I think it was a two. Synthesizes some orders. So we have accounts. We have grocery products. It sets up orders and order details somewhat randomly. So some people order a lot of groceries. Some people don't order very many. And then there's just a little bit of extra material here for regions and, and statuses for the orders, whether orders are new or processing. So this is all the data that we're gonna, we are going to put into our, into our database, just so that we have some of the work with. Choose raw, copy all of that, and put that into our, so we go back to the data tab. SQL, and we will paste that in. And that, that bake. See, Candice, do we have any questions? Is anybody puzzled by anything? We do have one question from Ivan. How does security work between client, the client and Hasara? Excellent question. So a couple of ways. There are a couple of things to say about that. So with Hasara, there is, there's authentication, of course, and then there's authorization. If we first take up the subject of authentication, Hasara doesn't do authentication, but it will use authentication. So we encourage you to use an auth provider, like Google or Auth0. Users, so a typical flow is a user coming to your application will get redirected to an Auth0 or Cognito login. They will log in. That will establish a session. And then there are two possible flows. One is, actually, so let me take a step back. There are two possible flows. One is with a webhook and one is with a JSON web token. With the webhook flow, the user will come into Hasara and then Hasara will, at appropriate point, make a webhook call to, let's say, Auth0, your auth provider, to authenticate you. Hasara will get back headers that identify the user role and the user ID. That's way number one. Way number two, the user will have a JSON web token by virtue of having it logged in. And that JSON web token will be presented to Hasara. Hasara will, JSON web token is a signed document. Within it, there will be, it's called custom claims, but they're basically credentials that again, say, would provide these headers for your role and your user ID. So that's how authentication is integrated with Hasara. That's authentication. Then there's authorization. So authorization, which is, can you perform some operations? Well, the way that works is that you actually do within Hasara. So Hasara has affordances for, let's say, paid the account table. This is a bit of data modeling that you do within Hasara. And these are, again, this is more business logic, but it's business logic that you obtain through configuration, not by writing code. You go to the permissions tab, you establish some role, some user role. You say, well, so first of all, this table here lists all of the roles that have been identified for Hasara. There's always an admin role. They have full permissions, but you would say, well, there is a user role. And you start to, you would use this to write fine-grained permissions over these types. So you'd say, well, by default, the user doesn't have access to anything on the account table, but we'll change that. We'll go in and we'll say the user can perform some operations, but we will say, call the custom check. We'll say, well, we wanna perform a custom check. And Hasara, when you do this, there's a little domain-specific language in here where you express what is the condition that must be met in order for the user to be authorized to perform this operation. You'd say, well, it's typically it's a comparison. So you'd say, well, I wanna compare, again, this is the account table. We know that the, well, we don't know this, but so the account table that I set up, it has the usual fields for a name, has created and updated it, has an ID. The ID is the identifier for this user. This would be the user ID. So you'd say, well, we wanna do a custom check where the ID in the row must be equal or it must match some value. Well, what value? Well, typically it would be a session variable and a specific one. In fact, it's helpfully, Hasara is helpfully offering to fill this in for us. It's accessory user ID, right? And so accessory user ID is the name of a session variable that will be in session if the user has gone through authentication in one of the ways that I just described, either with a web hook or with a JSON web token, either way, but as a consequence of that, there will be a session variable accessory user ID for that user. You'd say, well, do this custom check and what can they do? They can see all the columns, but again, this is just a select permission. Save this. And so then we go back to the API tab. Now, we can simulate this in Hasara's console. I don't have authentication setup, but we can simulate authorization. I don't have accessory user ID set. When that's true, Hasara will consider that I am the admin and I can do anything. So I can perform a query here. I can say, well, give me ID name limit this so that we don't get all of the data. And right, so we just performed our first GraphQL query and we have a list of users. But now let's say, but we're able to get all of these data because I'm admin. Why am I admin? I'm admin because I don't have accessor user ID set. Now let's say I, let's just copy this one for S-to-bond learning. Now I'll add this as a session variable, accessor user ID, paste in that user ID and then query to the demo gods. Let me do raw here and go back, make sure to count permissions here, those permissions, accessor user ID, go back here, accessor user ID. There we go. Well, did do it. All right, I'm clearly forgetting something. There's a detail that I'm forgetting, but I didn't pray sufficiently to the demo gods, but how that should work is you would just get back one raw. But broadly, so how, Ivan, I think the question was how does authentication work? There are the two aspects. You authenticate with an auth provider, you integrate that with a Sura and then you use permissions within a Sura to manage that. We'll just take that out. But as we say, we're now getting data and there are relationships among these data for these accounts. Let's just get one account. We can, let's see if this person has any orders. Orders. So this is an example of how related data are presented in Sura. And this is, we're getting mercifully to the near the end of the demo, I swear. So what orders, what products is this person ordered? What are their names? Let's talk about that. So, okay, so as Ivan has ordered milk and juice and pears and things of that nature. Yeah, so that's a Sura. That's a whirlwind of a Sura. Let me go back to my, I'll just, yeah, I'll skip that in the interest of time. Right, Sura product features. There is a time within Sura that we really didn't have time to cover. We covered the GraphQL API. There's a whole nother API that's available called Relay. Sura works, so in this case it's working with Postgres but it also works with SQL Server and BigQuery and we're working on other databases. There are actions, so Sura can call remote web hooks and that's a way, if you recall earlier we talked about one kind of business logic being side effects. So actions are a way that you can achieve side effects by calling like a serverless function. There are remote schema, which means that if you have other GraphQL APIs or even REST APIs and you want to integrate those or stitch those into a data model that you set up with the database, Sura will happily do that for you. There are event triggers, which is a way of setting up some asynchronous processing and you can run those triggers on a schedule. We did talk about authentication and authorization briefly. Sura will help you do database migrations if you want. There's a command line interface that will help you do all of this. So there's a lot of code in Sura that you don't have to write but which helps you build your application and helps you model your data directly in the database. Again, using all of the affordances that your database provides so that you really don't have to write that much code. That's what Sura does. I work for Sura and I think it's a great product. It is a great product, but there are some honorable mentions there are some other tools that do similar things there's something called PostgreFile, which is similar. It's a HTTP server, works with Postgres, presents a GraphQL API, something called Prisma which does something similar. There is something called PG GraphQL which is provided by a company called SuperBase. There's a startup, this weird little green symbol on the right, that's those folks. That's kind of interesting. It actually serves or evaluates GraphQL queries right in the database, right in Postgres. That's pretty cool. Of course, to serve those over an HTTP connection you need something else. So they use something called Postgres which will among other things present your database not as a GraphQL API but as a REST API. But you can use Postgres independent of that. And so if you want to present your database as REST endpoints, you can use that. But one of the things that pretty much all of these tools have in common which differs from, these are all web servers, these are all application servers. One of the things that is different from applications servers of your is that there's no place within these to put your code, right? Like if, you know, if folks remember writing say Spring Boot applications, right? You're writing your application server in Java then, you know, you're in your beloved IntelliJ and you can write your business logic code right in Java or if you are using Ruby on Rails, right? You can write your business logic right in Ruby, right? And in the application server. These tools for the most part don't let you do that. They do one thing for you really well which is automatically present your database as an API, but they very studiously avoid giving you a place to write your business logic. And the reason is, I would say in large part because it's becoming a good, we are re-remembering that it was, it's a good idea, it can be a good idea to write your business logic right in the database. So, you know, the title on the talk is how to write less code. Well, maybe my friend at Hasura is right. Maybe we just grant that SQL isn't a real programming language. Maybe we just say that it's not a programming language at all. We're not coding when we write SQL but then write our application in SQL anyway. If you can and if you do, then evidently you wrote your application without writing any code. And that's not, that's glib but it's not just glib. The database, modern databases provide a ton of functionality. And, you know, if we, there are many cases, I think where if we take advantage of that we can build our applications faster, more cheaply, more robustly, more reliably than we could do otherwise. If that doesn't sound that profound, it isn't. This isn't meant to be complicated. It's meant to be simple. That's part of the theme of this is, you know, we over the last 30, 40 years we went on a journey of increasing complexity but, you know, we turned around and we came back, coming back to Earth to building applications simpler. So I'll leave you maybe with just this one last to the quote from Turing Award winner, Asgur Deekstra, simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it and make matters worse complexity sells better. So that's pretty much it. Keep things simple, write your application in the database if you can, use all of the affordances that are provided and profit and that's pretty much it. Happy to demo other aspects of Hasura or answer any other questions that folks have but yeah, thanks for, thanks for attending. Candace, how are we doing? We're good, we got two more questions. First one is, is it possible to link multiple projects with same Hasura client and same database? So let's do this, a couple of ways of answering this question. So suppose you have, yeah, okay. With one database in Hasura Cloud you can set up multiple Hasura Cloud projects pointing to one database. There's a minor detail, it gets a little bit trickier if you're using the open source and your self hosting, there's a little bit of work that you have to do. The reason I say that is because in Hasura, there is metadata, like all of this information about what tables are tracked and what permissions are set up, that all represents metadata and we have to store that somewhere. But very hopefully in Hasura Cloud, we store that metadata for you. It's not stored in your database. So if you can set up different projects, each of which has, all pointing to the same database but let's suppose for some projects, in some instances you want to present or track certain tables and you wanna have certain permission schemes but then in another project you wanna do it differently. You can absolutely do that in Hasura just by setting up multiple projects. That's multiple projects pointing to one database but within one Hasura project, you can also access multiple databases. So let's see if we go to manage here. So we are already connected to one database but we can connect to more. We can connect multiple databases within Hasura. And then once that's been done, just like you can set up relationships between tables in Hasura, that's part of the data modeling process, you can set up relationships between tables in multiple databases and Hasura will join those data for you. You can also, as I said, there's this remote schema functionality where, let me jump over there, where you can add a connection not to another database but to another GraphQL server. But from the point of view of the API consumer, all of this is blended together into one GraphQL API. And again, you can set up relationships between from database to remote schema, from remote schema to remote schema. You can set up relationships pretty much in almost anything and Hasura will join those data for you. So there's a lot of flexibility for having multiple projects or multiple databases. I hope that answers that question. Candice, was there another question? Yep, there's one more. Are joins included by GraphQL for nested queries? Joins are included for GraphQL for nested queries. So, let's see how can we, so that's the nested query is what's happening here. We're saying, well, get accounts, but then for those accounts, get the orders and then the order details. Those are, from the point of view of GraphQL, those are one way to think about it is those are nested queries. But to perform that operation, click the analyze button, we can see the SQL server is writing and to do that, to perform that operation, it's doing the joins for us. So, absolutely, that is absolutely available. There's a lot that's available within Hasura. There's a barely scratch to surface in terms of functionality, but yeah. Well, I think that's just about time, but if there are any other questions or if folks have questions afterward, you can always, please reach out to me through, you can reach out to me. So this, the link that's provided here and that QR code takes you to it as well. That is a link to this GitHub repository that has all the talks that I've presented, but you can reach out to me through here. My email address is here as well. There are a lot of ways to reach out to me if folks have questions, but that is pretty much it. And I thank folks for attending. Thank you so much, David, for your time today and thank you everyone for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars and have a wonderful day. All right, thanks everyone. Thank you, Candice, bye.