Programming Throwdown - 159: GraphQL with Tanmai Gopal

Episode Date: June 12, 2023

GraphQL is one of the biggest API enablers in software development, but just how complicated can things be? Tanmai Gopal – Hasura’s CEO extraordinaire – talks with Jason and Patrick about how the secret sauce gets made. They dive deeply from how APIs function to having them managed in practice – among several other topic, making this a must-listen episode.  00:01:19 Introductions00:01:48 Tanmai’s late start in programming00:05:48 Plinko00:13:06 Coursera00:23:28 The question of API development00:30:30 API layer functionality00:34:58 How Hasura leverages JSON00:39:08 GraphQL00:42:49 Worse than an API call00:49:15 The potential REST minefield00:53:41 JSON Web Tokens01:11:34 Scaling writes01:15:17 Careers with Hasura01:22:35 FarewellsResources mentioned in this episode:Join the Programming Throwdown Patreon community today: https://www.patreon.com/programmingthrowdown?ty=h Subscribe to the podcast on Youtube: https://www.youtube.com/@programmingthrowdown4793Links: Tanmai Gopal: Website: https://hasura.io/blog/@tanmaig/ Linkedin: https://www.linkedin.com/in/tanmaig/ Twitter: https://twitter.com/tanmaigo Github: https://github.com/coco98 Hasura: Website: https://hasura.io/ Careers: https://hasura.io/careers/ Twitter: https://twitter.com/HasuraHQ Github: https://github.com/hasura Linkedin: https://www.linkedin.com/company/hasura Others: Good Strategy, Bad Strategy (Amazon): https://www.amazon.com/Good-Strategy-Bad-Strategy-audiobook/dp/B07R6XQ8YP Modern Application Development (IIT Madras, archived): https://archive.nptel.ac.in/courses/106/106/106106156/If you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM | Youtube Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Hey everybody. So we have an awesome episode here. I remember the kind of first time I saw GraphQL. And I remember it's just kind of a magical thing. We're going to dive into it. I'm not going to kind of spoil it or anything. But it is something that kind of really spoke to me. I think in general, when you look at the way that you can sort of design sending information over the web, I think GraphQL allows you

to do a lot with very little. It's a really powerful tool and I'm really excited to talk about it. A lot of people don't know about it. And so a lot of folks out there listening, this might be the first time you're hearing GraphQL. You might be thinking, oh, is this a new sequel or something? No, it's very different. We're going to cover it from top to bottom. And to do that, we have Tanmay Gopal,

who's CEO of Pesura, to cover it. So thanks so much for coming on the show, Tanmay. Thanks for having me. Great to be here. Great. Yes. So, you know, before we get into GraphQL, we always love to hear about our guests, like where they, you know, kind of came from in their careers. You know, what did you study?

Were you coding on Atari at four years old? Or did you start getting into coding at 34 years old? You know, what's the journey like? And what's the path that took you to Asura? So I'd love to hear more. I started programming fairly late in my life in university. And I think until I was in university, I wanted to kind of do kind of more pure science-y kind of stuff,

which appealed to me more. And then during kind of like my pre-university years the idea that we've kind of been able to create a world that is entirely on our own terms that is to a large degree disassociated from the natural law right like you don't have to worry about physics like you're building a bridge you need to care about like the wind and the earth right but when you're doing something on a machine and care about like the wind and the earth right but when you're doing something on a machine and we've kind of built this world of software and the internet it's kind of insane how that happened and so and how that happened and and and how we did that was

was just like an idea that was stuck in my head and i really wanted to find out how this was built and that's the reason I wanted to then kind of study computer science. And so that's what I started in university. I did my bachelor's and my master's. For my master's, I then specialized in... I covered a lot of breadth while I was in university on different kinds of computer science topics. And for my master's work,

I specialized in machine learning and computer vision. I did some research work that I sold off to the Defense Org in India. Wait, so let's dive into that a little bit. So I think if, and tell me if I'm not paraphrasing this correctly. So when you're doing your undergrad, it was in more of the hard sciences. And then for your master's, you switched to computer science, right? Pre-undergrad, I thought I wanted to do more pure sciences stuff. But then when I had to choose kind of a work stream for my undergrad, I decided to do computer science.

Okay, got it. So what was that like? So, you know, I think I had a somewhat similar thing where I was pretty sure I was going to be in math, like a math major. And then I got to college and I went with computer science. And so, you know, in your case, you know, what was that like? Like, where did the mindset change? And how did that evolve? I think it was like this, just in terms of the amount of things that we are able to do as humans, it felt like we could just do so much more because we created kind of this this world in our own terms right this abstraction on hardware that was software right that it's video games or

or code or the internet or whatever right so i felt like that's all i understood about computers i didn't even i didn't understand anything else i you know i'd used computers before of course and and i played around with programming in school i think once or twice and it was very interesting but then kind of that thing got stuck in my head because most of your school years right you're kind of studying you're doing like basic physics and chemistry and biology and stuff like that right and um and that was very interesting but i felt like from what i had studied to where the world was, there was a bit of a gap. And I wanted to kind of unpack what that gap was, right? It's like, sure, like we understand these electrons and things,

and we understand like, like we understand electricity, we're kind of, we had semiconductors, and we kind of get in there, like you're kind of feeling that the building blocks are coming together, but there's still a little bit of a leap before that just transitions into this virtual world or into this thing, right? And so I really wanted to unpack that. How did that happen? That's the only thing I knew. That was the only agenda I had to kind of figure out how that happened. And that's kind of what pulled me towards studying computer science. Does that make sense? Yeah, totally. Yeah. I mean, I have kind of a similar experience where I think

if you look at math and economics, you know, you build these models with a ton of assumptions and they're relatively simple models. And then you can, you know, like I'm thinking about differential equations here. There's probably a ton of others. But then, you know, you look at the computer world. And I mean, when I was in high school, Half-Life came out, the original Half-Life game. And I remember seeing there was this demo where there were barrels. They basically made Plinko. You know, Plinko from, it's this game where you drop a disc and you have a bunch of pegs on a board, and the disc kind of bounces among the pegs and then falls in one of the buckets.

And you assign points to different buckets. It's a lot of fun. So the Half-Life, when they were showing off the game, the developers basically built Plinko in the Half-Life engine, and they dropped one of these explosive barrels, and it just bounced on these pegs and went into the hole. I got really enamored by that. It's like, wow, what a complex system that these handful of folks

just created out of thin air. It's just something really powerful there exactly right and i kind of wanted to really unpack that and then that's kind of what the undergrad was like oh very cool so you went to grad school then you did a small company that was doing some work with the military and then then, yeah, what happened after that? After studying, when I wanted to kind of figure out what to do in the real world, right? I think during those kind of last few years in my undergrad and then while doing my master's, I thought,

maybe I want to do research. But then when I did some research and I was like, nah, this is still too slow. I want like a shorter feedback loop i want to be able to do something and then have impact and so then what i did was i just kind of went into industry and started doing my own like freelance consulting initially in the space that i was in and then kind of gradually just trying to understand take stock of what is happening with companies across the world and what are kind of the key challenges they're

struggling with in terms of kind of scaling their ability to build products and build digital products and take things to market and stuff like that and so for the next few years I started a consulting firm and I got together a bunch of folks from you know from university and friends and stuff like that and built out a small consulting firm. And what we did was we worked with companies of all shapes and sizes with, like, global, like, banks to tiny startups to, you know, brick-and-mortar companies building their first digital product and stuff like that.

And during that time, what we kind of did was we built products for them. And internally, a few of us have kind of like a platform team and what we were trying to figure out was what needs to be done to make this whole process of building things faster and and the reason why we set up that platform team was because me and my co-founder today at Hasura in in our previous company we wanted to build out a small application it was like a food e-commerce type thing just just for kicks and i thought it'd be really easy to build and and as i went through that process of developing the application i got so angry

i got really really angry i was like this is not okay like this is just way too much work yeah this is like we're doing too much work for doing. This is like, this was the time when we had like things like Ionic and Ionic was just coming out. There's a thing called jQuery mobile. I don't know if you remember.

Oh man, I remember that. It was, it looked so janky, right? Web components and polymer, like polymer web components

or something Google is just starting to come out, right? Twitter had a flimical flight. Oh, that's right. Yeah. So these kinds of little things were just starting to come out, right? Twitter had a flimical flight. Oh, that's right. Yeah. So these kind of little things were just happening.

But regardless, it was a time of tremendous amount of frustration, both on the front end side and the API side. It was like, we are just doing too much work. We don't need to specify so many things. I mean, computer science has moved on. Yeah. I feel like in many ways, mobile is still frustrating. I think on the web, for example, if you want to plot a time series on the web, you would just go to GitHub, you'd find

a time series library, you would add it to your package.json file, and you're good to go. There's solid documentation. With React, you have pretty good isolation among the different components. You don't have to worry about that. On mobile, it's still a mess. If you want to plot a time series on mobile, you go on GitHub, you find some graph package that probably has like 13 GitHub stars. You plug it in. Oh, it's in Java and all your stuff's in Kotlin.

And now you have to deal with interop and everything. And it's like, oh, I can't render on the main thread. It causes an exception. It's just like, it's just the experience is very painful. And so, you know, that's the thing that when these things started coming out, like Cordera, I think was one, Ionic, these things where you could take your website and put it on the phone, that was so appealing but then as you said they were also super janky you're in this kind of uncanny valley where it worked enough

that people knew it wasn't a native app and they didn't like it and it's just it was it was totally frustrating yeah exactly right and and so we i was like we have to fix this we're going to do something so that so that we improve this and the number of developers in the world ought to be like hundreds of millions, right? It's still just tens of millions, barely. And so it needs to be hundreds of millions for the amount of impact that this has.

And the world is going there, right? We are on that trajectory. It's not like it's not going to happen. It is going to happen. How do we help accelerate that? What are the pieces of the problem that need to be solved to kind of make that unlock

as systematic as possible, right? As like as systemic and systematic as possible. And the technologies that really appeal to me and that appeal to us in the founding team were things like, you know,

databases really appeal to us and programming languages and compilers really appeal to us because it's such a nice way of translating like a higher level way of thinking into a lower level abstraction that something like a machine can understand, right? And databases are such a brilliant example of doing that, right?

Because if you don't have databases, like you'll be reading and writing to files every time you wanted to build something instead of kind of capturing domain models and saying, oh, I have a time series model and so chuck it into a time series database, right? Or have an unstructured data model, chuck it into a JSON database. I have a structured table with relationships and that's my domain.

And so you chuck that into a Postgres or whatever, right? So those things were really appealing to us. And we were like, what needs to be, something needs to be there to make this process easier. And so with kind of a phase of like a lot of experimentation, a lot of learning what companies and what the industry is doing we were super early in kind of the cloud native ecosystem we played around with docker and kubernetes both when they were pre 1.0 we built the world's first kubernetes operator so that did did like a tremendous number of uh super early in

the githubs movement as well i had one of the the first Git push to set up and deploy Kubernetes-based applications. I remember speaking at one of the first KubeCons. So we did kind of a bunch of things to understand kind of where the industry is going, what kind of things are happening, what kinds of interventions are required. One of the other things that we also did during this time was also like understand what the gaps in learning are.

And we ran this course on introduction to modern application development, which we kind of just said, all you need is a browser and you're going to learn how just web application development works. Wait, let's double click into that. So how did you get to running that course?

Like, did someone approach you? Did you go to Coursera and say, I love your platform or like whoever and say, I love your platform. Let me put a course. How did that happen? I went to a professor that I knew in university who I quite liked. And I went to him and I said, hey, we should just do this course because like, university doesn't teach it. The university that I come from in India is a fairly famous university and they do these. It's a part of a network of universities that do a lot of online courses

is this iit i've heard the word iit before okay yeah yeah yeah this is one it's an it's an idea and so they run these online courses that like everybody like a lot of people in india kind of use which is usually more advanced engineering courses right and so what i said was hey let's do this course where we kind of introduce like modern application development right because nobody really like it's not covered in the university syllabus and people don't people really want to understand it right it's like i'm using this google.com thing for search how what what happens right like how is this thing working like what's the what are the layers here uh what are the concepts here that come together

to make this thing work, right? And then obviously give people a feel for like writing a little bit of a hello world and then seeing that work inside of a browser. And so we put this course together. We built like a browser sandbox environment where you can write code and you can see a website go live.

I think it became one of the largest Kubernetes clusters at the time. I think it had like a 700 node cluster to power this because we had like 250,000 students in a year that went through the program. And that was fascinating as well to kind of take a look at and see this is how much people really want to learn. This is how much people really want to do and have agency and understand how these things work and then use it to build something. Yeah, I feel like, you know, just

double click on that. I feel like, you know, I'm a big fan of university. I mean, I got a PhD. I really enjoyed my time there. But, you know, one of the things that it did not prepare me for is writing modern software at all. The code behind my PhD dissertation, say the PhD project or something, it was all just XML files. I was like by hand editing XML files to configure everything. And even when I was writing all the statistics out, I was writing those in JSON and XML files and then trying to by hand look at it. And I remember at one point writing a Python program to like read in an XML

file and compute the average of all the entries in the file. And basically, like I could have probably graduated half a year earlier if I had just someone had just told me what SQLite was, you know, or MySQL or whatever. Like, yeah, I had no background in databases. I had no background in networking. And I was completely ill prepared to build anything significant. And so, yeah, what you're what you're touching on is extremely, extremely powerful. And so no matter how, like, theoretical you are, just take the time to learn how to build a modern you know website or a modern app it's so important yep yep and and and for everybody across the country right i

remember we had like some of the students who joined that course for people who were like professionals you know who'd worked for a decade two decades in a completely different industry not even like technical or sciencey and or just're just like, I want to build a thing. And, you know, I want to see what it feels like. And it's fascinating, right? Because like you can actually do it. Like you can convert an idea into a thing. It's possible today.

So we did a whole set of things basically is what I'm trying to say. And of all of these things that we did, the piece that stood out to us the most was this idea that when we kind of take a step back, this is around 2018, 2019, when we kind of take a step back and we look at where the industry is going, our hypothesis was that the data experience is going to keep improving. We were in a world in the 80s and 90s when the databases first came along,

which became the perfect place to model your domain and then interact with your domain, right? That's what the database became. It said, instead of you trying to screw around with files, why don't you chuck stuff into a table and then you have this amazing language like SQL to be able to query that database and interact with it. Right?

And that was amazing. And then we kind of went through this thing where the database companies became a little too greedy. Everybody wanted to buy an island or two. And they kind of really penalized, right? They really penalized people in the industry to start actually working and having business logic in the database and doing things like that. And so people wanted to start taking that outside of the database.

And so they started building applications that would let them interact with the database, right? And so you build applications. These applications that the internet came along became application servers and HTML, which became like the front end, right? So it kind of like went from one place where things would happen into two, into three, right? When suddenly you had the web as well. And then 2010 onwards, that like the third end of it, the web experience, the mobile experience became very rich

because of the mobile kind of improvement that happened. And with iPhones, smartphones, whatever. And that's kind of where products were getting built, and then we had these apis in the middle and then you had data stores and those data stores were scaling for a long time right like 2005 onwards everybody was very frustrated like my databases are not scaling but then again around 2015 2016 we again reached kind of that point where databases figured out how they're going to kind of become more scalable. And we started seeing the first distributed relational databases, we started seeing the NoSQL databases also adding more database features, becoming closer to relational databases, but also kind of providing that kind of read-write performance at scale.

Yeah, that's an interesting story, right? Like, you know, MySQL, Postgres were the biggest thing. And then there was a period where it was all HBase, Cassandra, and all of these type of efforts. But then it seems like we've almost gone back. I think what it is, is MySQL and Postgres are so much easier to shard now, that people have kind of gone back to that and hbase is probably you know just a less than one percent yeah yeah it is it is still too low level right because you can get because what is amazing about postgres and mysql is how rich they are and their capability and what you can do with them they just want scaling and then people figured out how to make them scale and now so we're back to kind of being able to use things like postgres and mysql right so when we kind of like looked at the data industry right we were like we looked at the database industry we were like the database industry is going to keep figuring it out they were in a place where you can now have a managed database and if you choose your workload

and you map your workload and a part of your domain right whatever your domain is you map part of your domain and you choose the right kind of database for it. You'll get like really, really good scalability, right? It'll keep working for you for a really long time. Like you can, you'll have to start kind of touching like Facebook, Google scale for you to start stressing out about your database. But short of that, you're probably not going to have to stress about your database at all.

It will just be a managed service that runs. You know, you can say that it's a very heavily transactional or it's super relational or it's time-saving or whatever it is, right? Well, now there's even the serverless, like there's Aurora from AWS, where it's a completely serverless MySQL. And I don't even know honestly how that works because they have to reverse engineer your intent. You know, it that works, because they don't, they have to reverse engineer your intent. You know, it's like, you don't really, I don't think you even have that many knobs to tune. But just as your demand scales up, it sort of figures out how to distribute that load. It's remarkable.

Yep, yep, yep. And like they separated, people started learning this idea of like separating compute from storage, right? And then really exploiting cloud. And that's how they managed to do this, right? And the OLAP ecosystem is improving. The time series databases and real-time analytics databases

have gotten really good, right? Whether it's like you look at the generation of like OLAP and data warehouses that really took off on the cloud, whether it's like Snowflake, BigQuery, Databricks type systems, and then you have like the real-time analytics versions of it, like whether you click house and do it in Ign real-time analytics versions of it, like Clickhouse

and Druid and Ignite and SimpleStore. It's amazing, right? There's no one database that's going to do everything, but you can take bits of your domain and chuck it onto the right data stores, and it's great. It's just phenomenal. It works. Yeah, and Clickhouse is completely open open source so it really kind of took the bigquery snowflake ecosystem and and now it's like almost becoming a commodity as soon as

someone open source comes on the market it completely disrupts everything yep exactly right and so so we kind of were getting the sense that this is going to happen so this experience is going to be amazing so kind of when you're thinking about building a product, you're like, okay, so the data stack is going to work. That's great. And it's going to keep improving. It's going to keep fragmenting. It's going to keep improving. But that's great, too. We look at the product building side of things, right? When you're looking

at your JavaScript frameworks and whatnot, we started seeing early signs of React becoming very popular. The meta frameworks in React were just starting. And it looked like that experience was also on its way to becoming... There was this continuous increase in complexity, as always, and fragmentation.

But that experience was getting better. And at least if not... All of us in web development think that we're still doing a little too much work on that side of like building the product and like trying to wrangle like 10 javascript libraries to doing something and whatever but it is continuously becoming better and and at least what you have there is what is happening is the agency is really high meaning that you're kind of able to go build a thing and then you're able to refactor that and change that and do something

else and like keep evolving very quickly right like your best practices evolve quickly but then you can start using them in production also pretty easily which is great because if that's happening that means you can keep evolving right and so you don't need to do one um and so the product building experience was getting great right the part that sucked from our point of view was the piece in the middle, which is this piece of API development, right? Because we're like, this API development piece, our gut sense was that we aren't adding too much value here, right?

There is something that needs to be done, right? But why is it not product and data? Why is there this middle layer of the API, right? And so we kind of took a step back and said, what if, what if products that are end user facing, right?

And that might be running on your device or your browser or being run in a different organization or different team in my company is running this product. Why can't that product speak to my domain data directly? Why? What's this thing in the middle? Yeah, the thing that has been there for a while, and I'd love you to burn this straw man down, would be ORMs. I think the superficial answer is, oh, we've had ORMs forever. Correct, correct, right? We've had ORMs forever.

And I think even with ORMs, right, when you think about it, the question really is, so you have a front-end application, right? You have a bank, like an application, like a bank app, right? And your bank app needs to do a transaction or whatever, right? Why can't the bank app talk to the bank's database directly? Why can't it just speak in SQL? That's what we used to do. That's what all developers know, right?

Assuming it's a SQL database. So why not just do that? Why does this app then speak to an API in Rails or Node.js or Python or whatever it is, right? And then we have an API. It speaks in http and json and you have an api and then this api things use an orm like you said right and then that orm then speaks to a database like the orm is like a translation layer so that you can translate like python concepts or node.js concepts or typescript concepts into sql if it's a sql database and then

it runs against database but why do we have these layers in the middle? Is it worth having these layers in the middle rather than just telling developers to just use SQL? Right? To interact with it? But what's happening? And so, when we broke this down, we said that the hypothesis was

the only thing that is happening at the API layer, like, the only thing that is happening at the API layer, like the only two things that necessitate this API layer is one, a performance problem, which is that databases don't handle high concurrency really well. They're getting better, but they're still not able to handle

like 100K, 200K kind of concurrent users. They prefer having 1000 concurrent connections, as opposed to 10,000 concurrent, like 20,000 concurrent HTTP users. Yeah, let me let me actually just, if you could bear with me, I'll dive into that a little bit, give a little detail for the audience. So, you know, when you have this API server, you know, it's handling tens of thousands of requests, maybe thousands of requests a second even, but it has a relatively small pool of database connections. And so it might be that a lot of those requests could be waiting for, you know, a spot in that pool, but that keeps your database from blowing up. Exactly, right?

And you multiplex them, right? So you realize that a thousand of these requests are kind of requesting the same data, but you keep the connection open and you pipeline those concurrent requests over the same connection, right? Because databases like having, they like having long connections that are open for a long time

and they do a lot of optimizations with that. They don't like it when you frequently disconnect and reconnect and do things. It kind of breaks some of the optimizations and stuff that they have, right? So that pipelining and preparing those statements and pre-compiling query plans and everything works better when you have a long connection that lasts as opposed to short connections that come and go, come and go, which is the more mobile traffic, right? And so you have this layer in the middle. And I think the second critical reason

behind that API server is security or authorization, which is that things and products that are running can't access those data systems directly because the business model of applications on the internet is based around centralized data and centralized logic. That's the business model of the internet, right? Of like web 2.0, right? Let's not do crypto. But like the business model for the internet is that I have some centralized data and logic as a company and I'm going to make that available and I'm going to be the trusted source of the centralized data

and I'm going to make it available to all these users who are running in insecure private contexts, right? Like your device is your phone. You technically, even if you don't like understand the machine, that code is yours. It's not running in the security context of the company. So your bank app, the code is insecure because the code is running with you.

That has to communicate and run a transaction or do a thing. But that is centralized data, right? So that is centralized logic. So you're crossing the security boundary, right? You're crossing this boundary of like, somebody is requesting a thing and we don't trust them. You're converting that into an action that is trusted and saying, yep, we understand this action and we can go execute this action.

So that authorization problem, and if you break down what authorization is, it's input validation. Somebody submitted a form. Is this form correct data? You don't trust it because it's coming from a form. Somebody is like filling in some junk there, right? Or somebody's being malicious.

So you don't trust that input. So you validate it. Give an example here. Like if you're listening at your computer, don't do this if you're in your car and you're unless you're at a red light or something, but actually, I don't know if you can do this on mobile anyways. Anyways, if you're, if you're at your computer and you're listening to the show, you can go to any website right now. You can right click on

anything and you can, there's a button called inspect and it'll take you to the code and you can go in and change it. Like you want to make, you want to make Twitter, you know, my Twitter, you could just go in now it won't show for anyone else, but for you, it'll show. And you can even change what you send to Twitter or any, any website. Like you can send it literally anything you want. And so it's, it's completely, you know, in your control, it's your code. And, and so that's the, that's the problem is if you have now full access to the database, you could say, oh, hey, Chase Bank, I have a million dollars now. Exactly. Give me everybody's data and whatnot.

So I remember one of those initial demos that we used to do to help people understand websites. It's like you open up a popular website and then you inspect element and you open up the HTML and then you'd go to like, you'd inspect element, and you'd open up the HTML, and then you'd go delete that HTML node. And suddenly the website in front of you would change and you'd be like, oh, the logo just disappeared. How did that happen? And then you're like, well, this is what it is, right? It's the code is sent to you. And you're running the code in your context. And it's your machine, it's your machine. This code is now running with your security context. And you can own it and you can change it and you can do all sorts of wacko things with it. And so that

this API layer is essentially, at its core, solving just two problems. It's solving this problem of arbitrating performance. And performance is subtle. It's this concurrency issue. You have speed of light issues. Your centralized data base is in the u.s and then you have um users in china

and they're like what i'm like the speed of light rtt itself is about like 180 milliseconds right across the world twice and you're like i mean it feels laggy right so you want to cache things that are closer to your users and stuff like that. There's like physics problems where you're still kind of restricted by this experience that you can have with a system. And so you have these kinds

of performance issues that you need to solve for. That's kind of one category. And the second category is essentially security and authorization validation. But in our minds and our kind of hypothesis for building the company was saying, these

are the only two problems that need to be solved. Everything else is just legacy. Everything else is people just doing things because they just do things. Yeah, I mean, that was one of the beauties behind the beautiful things about things like Next.js, where you're writing your front end back end server. So letters, but someone could just say, oh, I'm going to post a new username API with a two-letter username. So, okay, now on the server, I have to say, okay, did this person disable the two, the three-letter check on their browser? And so the cool thing about things like Next is, you know, you would have the same logic on front-end and like the same, literally the same code on front end and back end, but on the back end, no one could mess with it. But, but it's even

with something like that, it's still a hassle that you have to think about everything twice. Yep, exactly. Right. And you still have to think about it twice. And then when you think about like, where's my security rule, is it enforced in the right place and whatnot. Right. And so the, the idea then was to say, if want to automate api development and we want to automate this middle layer so that people can kind of go build products um including things like you know build it with next.js or build it serverless or build it with uh build apps right uh go ahead and do that and use these managed data services that are continuously getting better but this middle piece should just be automated. It should just be an implementation detail.

It should be magic that exists. It's expected. It's an expected part of your infrastructure. And so what we did was we built an engine where if you can provide like a semantic model of how your data models become domain models, right? So you say that here's a user table uh inside this database and here's documents inside that database and together they become a user model and a document model like they convert into logical models that you have that represent your domain so if you can do the modeling and do

each of these models you can attach all the authorization rules that you'd ever need whether it's input validation what who can access them, really complicated rules. Like you can say, allow accessing a document if it's public, or if the current user is a collaborator, or if the current user is a family member of whoever owns the document, right? And there's hierarchical rules, there's all kinds of stuff, then certain fields are hidden and masked, whatever, right? Like it's all just, we call it authorization. So if we have a nice system to model and to authorize those models,

then we can just create the API automatically. This is the only domain-specific work that needs to be done. That's all you need to do. Nothing else should be written by hand, right? If we have this information about what your models are and how those models are secured, then we can generate the API that has pagination and the ability to fetch from multiple sources in one shot, the ability to write data securely, the ability to read data securely, cache it, have HTTP level

concurrency, do all kinds of things that you do by hand. But we can automate a whole chunk of that by saying that the user just needs to work at this meta layer, right? This domain layer. You think in models and you think about your domain and you don't do anything else. And so we built our own JSON API that does this. So we have like a metadata language, a domain specific language, a DSL, which is in JSON essentially. So we have like a metadata language, a domain-specific language, a DSL, which is in JSON, essentially. So it's like a JSON configuration. And in this JSON configuration,

you provide the models and you provide authorization rules of those models. And you submit that to the Hasura engine. And the Hasura engine essentially just becomes the API. So instead of you writing code and then compiling that

or running that inside an app server, Hustler is an existing app server that's already running, right? And then you just give it the configuration of your domain, the description of your domain and the models, the concrete description of your domains and models, and bam, we become the API. And we launched this in 2018. Open source became really popular. I think we went from like 2 million to 100 million to like a billion downloads over like the next few years.

And that kind of brings us to today. Yeah, this is awesome. So I definitely want to know more about the authorization piece. But let's start from the foundation here. So what you were talking about, you know, you have either a website or a mobile app, and that app, you know, transfers information to a backend server. And with something like Hasura, that backend server is auto-generated, but it's still running so that it can, you know, make queries with an elevated permission, right? And so it's talking to the database. So, you know,

imagine a sort of mental model where you have front end, you have your front end server, and then you have your database. And you might even have back end servers if they have to do some complex thing like image processing or something like that. So that gap between the front end and the front end server, that gap is covered through HTTP calls. So you make an HTTP request, say, log in, or you make HTTP requests, say, get my profile. And if you're doing something with traditional REST, the way those look is actually not that different from the way a website works.

Like you go to google.com slash search, and what you're going to get back is some HTML content. And your browser knows to render that as a website. Yeah, if you go to google.com slash and I'm making this up, but slash API slash, you know, foobar.json, then your browser is going to get some automated, you know, some some machine intended content. And it's going to render it again, like maybe you'll get this, depending on your browser, you might get this nice UI where you can fold parts of the JSON and stuff, but you're effectively getting stuff that's meant for a machine. And so then, you know, putting it all together, when you go to google.com slash search, you know, that HTML and that

JavaScript will now have commands to get other websites. And those other websites are enriching that user interface with more data. So maybe the latest weather or something comes in through a separate call. And you don't see all you can see all of those calls, you know, if you go to the developer mode. But by default, you know, you're only seeing that main website just under the hood. It's making all of these calls. And so, you know, REST is the simplest.

And is REST an acronym? I think it is, right? Yeah, I think it's a representational state transfer, I think. Oh, look at you. Nice. So, yeah, so REST is the sort of like canonical, like the version 1.0 way of doing this. And basically, you have query parameters. And this is just like a regular website.

You do question mark, A equals B, C equals D, E equals F. You also have a post body. So if you're making a post HTTP request, you could put a bunch of JSON or XML or whatever you want in the body, YAML if you want. That goes to a server. That server now has to take the query and the body of your request, figure out what you intend to do there, And then it can return, you know, some arbitrary information. So what is GraphQL? Why is it invented? You know,

what's wrong with REST? You know, what is it doing, doing better than all of that? Yeah, yeah, absolutely spot on, right. And then when you can kind of just build on top of that, remember when you mentioned that, like when you have like a google search page or something that comes in you do have data sometimes coming in not just from the primary google server that surfaces like the search results but you have like that weather information snippet thing coming in right and you have like you have other pieces of information that are also required for that one page that you're viewing right and so what started happening was that as mobile applications became more complicated, we wanted to do more.

We had the opportunity to have a richer experience for a user. And the user could see more, right, on their screen and they could interact with it more. And when they wanted to see that information, right, you'd realize that you have to now hit multiple different machines and services and data sources to fetch that data, right?

You are rendering a profile page. So you want to show the account information, but you also want to show the recent orders that this person has made, which might come from different services, right? Different API services or different data sources that are storing that information. Because remember, we're not in a place

where we can store all of that data onto one single database, right? We are storing that in multiple sources of data. There's multiple ways of interacting with, there's different ways of interacting with these different sources of data and whatnot, right? And so when you're seeing that profile page on an e-commerce website, you're seeing that account information coming from one place, you're seeing a recent order activity coming in from one place, you're seeing your last five addresses, right? Saved cards, whatever.

These are all like different sources of data that are then being unified into one thing. So what started happening was that people started getting frustrated with saying, I'm having to make too many API calls to fetch this information. And this frustration caused, like showed up in two ways right the first frustration was as a developer when you were like i can have one gigantic api con that fetches everything right like i'll build an api server that does this work for me it goes and fetches all of the data in one shot and then returns this giant thing to me right and then this frustration showed up as like every time i want a

different slice of data it's painful so i'm on a mobile screen i want to show you id and name on the page and i'm on a web screen i want to show you id name age email address right so i want to show you a different slice of data because if i show you less data i can transfer it faster cheaper bandwidth cheaper battery faster experience or if i want to show it on your desktop screen, you typically have like a better internet connection, your computer is more powerful, you have more real estate, you can show more data, right? Now, as a developer, when I'm building these products, every time I have a different slice of the same data that I want to show somebody has to go build

a new API somebody has to build an API for five fields for 100 fields for 50 fields it's a pain like you have to build new API endpoints for each shape of your data that you want right that was kind of one frustration right the second piece that showed up then was when you're integrating multiple API calls into the building experience, it sucks. It really feels, it's terrible. It's like the worst part of building the product is integrating APIs, right? It's like, you just want to build the product. You don't want to integrate APIs because an API is asynchronous. So you fetch data, you have to wait for it. Then the screen loads up. Yep, and you have to do something while you're waiting, you have to make the little loading spinner

and everything. Yeah, exactly. The only thing worse than an API call is multiple API calls. It's the only thing worse than having one API call on the thing that you want to build. You're like, goddammit, there's 50 now on this page, right? And so, it's very frustrating.

And so, a bunch of people tried many different ways to address this issue right yeah there was there was meteor that was a thing remember meteor js correct meteor was a thing that tried to unify it around like a mongo thing that the apollo folks did then we had i think the approach that was trying to create this back-end for front-end type situation was falcor by the netflix folks microsoft had something like odata there's a whole bunch of like microsoft sap there's a whole bunch of approaches and then the facebook folks created a specification for something called graphql which was essentially a more structured way it used a subset of the same concepts that we had in rust so you have like a

the intention is to say that you have a post method on a HTTP endpoint, but the post method now sends a query, a richer query that describes all of the things that you want. And the API server is now a more capable API server that can understand this query and fetch data from multiple

places as required and then return that. So you're giving more control to the product builders and saying, you tell us what you want, and we'll fetch it. So you tell us if you want a user and just the ID name, that's fine too. But you tell us that you want the user, ID name, last five addresses, last five orders, that's fine too.

But all you have to do is send us one query on the API server, right? Kind of like a SQL for APIs, right? You don't go to a database and then you don't go to the database and you're like, hey, so give me one row from that table. Yeah, now give me one row here.

And now do that. And now you don't do that. You don't restfully interact with the database, right? You interact in a richer way like SQL. GraphQL brings that to the API layer, right? You're having a rich interaction with your APIs. You're fetching the slices of data that you want. And that kind of was the genesis of GraphQL brings that to the API layer, right? You're having a rich interaction with your APIs. You're fetching the slices of data that you want. And that kind of was the genesis of GraphQL.

And it became an amazing API to consume for people who are building products. It was a lot more intuitive. I had to do slightly lesser work than integrating multiple endpoints. And I say slightly mildly, you had to do a lot lesser work when you had to integrate multiple endpoints.

And the query language felt nicer. It felt like it's the part of the JSON that I want, right? So that's kind of what GraphQL is like. It's a specification. It's exactly like SQL is a spec or REST is a spec or gRPC is a spec. So it's just a spec. And that's what GraphQL was. Yeah, that makes sense.

So I was trying to tie back to Husserl here. is a spec. So it's just a spec. And that's what GraphQL was. Yeah, that makes sense. So trying to tie back to Husserl here. So with the rest, you had a really good point, which is, I want to get my redacted profile or my profile with just my name, or I want to get my profile with my age. If I want to do this in one call, then I can have a query parameter that says return age, true or false. If it's true, then I get the age. And then if you take this to its logical limit, then it's like of everything I could return, you know, in my request, I say, yes, give me the age. Yes. Give me the name. Yes. Give me the profile. No, don't give me the long description. And so taken to its logical limit,

you end up with something like GraphQL where it's like, here's the things I want to return, and then everything else I don't want to return by definition. Exactly, exactly. And then, you know, tying it back to authorization, the thing you have to really watch out for is, if you're not careful, you might be able to say things like, give me Patrick's bank account. And so, and so like with rest, you know, because you're doing it, it's almost like the, you've seen this argument since assembly, like there were those people way back in the day who said, Oh, you know, with assembly, I have all this extra control because I'm doing all this extra work. And any of that's true, but you pay for it in efficiency. But yeah, with, with rest, it's like like you clearly see, you know, if there's an API call that

says, you know, give bank account, you know, you're begged to wonder like, okay, am I making sure I'm not getting everyone's bank account? But with GraphQL, you can end up with a blind spot where you accidentally allow someone to get someone else's information. Exactly right. I think you have to be very careful in how you're building a GraphQL because with great power comes great responsibility, right? Like you gave more power to the front-end developers

or product developers, and then now you're like, whoops, somebody's gone to absorb the complexity or the increase in our footprint of being, if you're able to serve more, then you have to make sure that all the ways that this data is being served is secure. In REST, you control that like as an API builder, like you decide, well sure that all the ways that this data is being secured. In REST, you control

that as an API builder. You decide there's five API calls. That's all you get. And so for these five, I'm going to manually make sure that each of them is secure. But with GraphQL, the space is infinite. You can say, I want a little bit of this and a little bit of that and then together. And I want

this and this and that, like A, B and C together, but bits of A and bits of B. you're like fetching the data in a bunch of different ways right and so the surface area is larger and the way that we think about it is everything should be model driven we should separate the idea of the api protocol from the idea of the model because in your domain what is important is the models that you have and the authorization rules are attached of the model. Because in your domain, what is important is the models that you have and the authorization rules are attached to the model. It is independent of what API, like what protocol is being used

to interact with that model, right? So if I have a model and you have REST APIs to do CRUD or you have a GraphQL API to query and subscribe and mutate, it doesn't matter. The point is that the model has a description of what it is and what its fields are. And its authorization policies have a description of what valid input for this model is or what valid ways to read it are for different kinds of users and roles and what should be redacted and what should be masked or what should be encrypted, whatever, right?

Like all of that is data associated with the model. Because once you put that close to the model that's where your business is so now when somebody wants to go review and be like what what went wrong with like our users that we like leak information or whatever you don't actually care about graphql or rest or grpc or mq2 whatever right like that doesn't matter what you go do is you look at your model and you're like hmm i see what went wrong. Or yep, I'm guaranteed that this actually works because my security rules here are okay. As long as these security rules are okay, who cares about what the API does? I can solve that problem at a different way. Yeah. So in a way, REST can create this sort of landmine. For example, you might say,

get my bank account balance. And in my bank account balance REST call, I check to make sure that I'm me and I'm not getting someone else's balance. Then someone else comes along and says, get me my 10 most recent transactions. If he doesn't have that same logic, now you've exposed a hole. And so if you have 100 REST APIs, all 100 need to share. And so you might as well just put this in a different layer to begin with, right? Exactly, right? You might as well just do all of this at the model level. Because with REST, what happens is that because the surface area is so small,

you're tempted to put all of that in the controller logic, right? You say, oh, you know, I only have five API endpoints. Why don't I secure each of them manually, right? And then before you know it, you're screwed because like the business keeps evolving and growing, right? And now you're like, nobody can even think about it. Nobody can even answer that question, right? If like a security person comes in

or a product or business comes in and they're like, so how exactly are we securing this again? Nobody but a developer or two developers or like whoever wrote that old code, a new code, they all sit together, eyeball it, and then, then you know maybe they know what's going on yeah right right i'm surprised are there are there actually uh like things that sit in between sql and you know i mean i think asura has something are you sitting like, is Hasura built on top of a, you know, model authorization library? Is that a thing?

So we invented it basically for ourselves, right? So we invented a modeling system and a policy language that allowed this to happen, right? And so that's what we built for our product. We said, if we can capture models and we can capture authorization rules on these models, right? And we're releasing this model and authorization system as a framework. And we're releasing this as a specification for the community at large so that anybody can use this specification to build services, right? So Hosser uses this specification to provide an API.

But technically, you can imagine where if I have the system that describes models and authorization rules, technically I can generate Rails code from it or JavaScript code from it or Java code or.NET, doesn't matter, right? Because it's a concrete specification of what a model is and what the authorization rules are. So I can convert that concrete specification into any language or runtime that can then become the API. And so that's kind of what we're doing and something that we're going to talk about

at HasuraCon, where we're going to kind of release this internal spec that we have that makes this so easy. Because as a human, you just care about, here's the models, here's the authorization rules,

now go figure it out. I don't actually care about details. Right? Like, yeah, go write the Java code or whatever. Like, who cares? It's like, it's a shitty implementation that i don't care about right like let it just run but this is the concrete information that i care about and this is this is going to take you 80 90 95 percent of the way

right how do you connect this with things like like cookies and all of that so if you want to know like okay you know this you can access this information if you're logged in as this user. And now you have to like tie in cookies, maybe even Okta. Yeah. Like, how do you tie all of that together without being bound to one language? Right. Yeah. No, that's a really good, that's a really good question.

Right. So we separate authentication from authorization. Right. As, and the industry does this as well. And then in our framework or like in our metadata, we do this as well, right? But what we do is we tell users that in your authorization policies, you can always reference

the current users or the current sessions properties, right? So you always say in an authorization policy that allow access to this account if account.owner equal to current session.userid, right? Or some property of the current session. So you can basically create complicated Boolean expressions, hierarchical rules that are essentially properties of the data, evaluate and properties of the session that are put together and that expression is evaluated. That essentially is what determines whether you have the ability to access something or not right that's essentially

what all your authorization code is the piece where you convert a cookie or a token into the session information that's a separate piece that you need to kind of specify as a mapping the very nice thing is that, the industry has kind of realized over the last few years that a nice way to approach this problem is a JWT, a JSON web token. So if our cookie or if our header, our authorization header,

contains a JSON web token, then a JSON web token is a secure contract. Slightly painful compared to like vanilla, EOB cookies from like 15 years ago right those are much simpler so the jwt adds a little more complex significantly more complexity but it's a common specification that everybody uses octa and not zero and not zero is octa and all but you know everybody uses that jwt now and the jwt is a secure way to to pass on those claims of who the current session is. So in your authorization rules, when you're saying, I want the current session dot something,

I want current session user ID, current session role, current session region, right? That's a contract that you can specify in your JSON web token. And you can say that my JWT is going to contain these claims. So use these claims to enforce some authorization policy, right? And then when you spin up your web servers, you give them the right keys to be able to decrypt and validate these JSON web tokens. So that's kind of the contract that we have.

And that's what makes it easy for everybody to use, right? Like not just us, but like everybody in the world. Got it. Okay, that makes sense. So you do provide like some, so by you, I mean the person using Hasura in this case provides some shim where they say, okay, you know, here's some code that I know Hasura is going to run on server side.

This code goes to Okta and, you know, verifies that this cookie is valid and it gives me a list of groups they're in and their, you know, userifies that this cookie is valid. And it gives me a list of groups they're in and their, you know, user ID and everything. Exactly. In fact, with JWT, it's even simpler. You don't need to make that call. This is the reason why people really like JWTs

because with microservices, everybody realized that when a cookie is coming in, they're going to have to make this extra API call to validate that cookie. So people wanted to skip that step. So the JSON web token itself contains the user ID and information. It contains all of that information already. So you don't need to make an extra call to skip that step. So the JSON web token itself contains the user ID and information. It contains all of that information already.

So you don't need to make an extra call to Okta. What you do instead is you have a key that Okta gives you to validate that the JSON web token was created by Okta in the first place. So that way, it's like somebody sending you their user ID and saying, hey, I'm Tanmay.

But then you're like, says who? Right? Like the API is like, you their user ID and saying, hey, I'm Tanmay. But then you're like, says who? Right? Like the API is like, you're saying that you're Tanmay, but are you really? Like who told you? Like who verified this? And then you can verify that signature and says, oh, Okta says you're Tanmay. Then you're like, yep, I have Okta's key. And so I trust this.

So that's the, so you get to skip that extra lookup step. That's the detail with the JWT. That's the benefit that you get with the JWT. But to your point with with Hustler, we support both of those modes. We support this JWT mode, and your second point, your first point, we support the shim also, where you can provide us a piece

of code where we can call out to you to do this lookup if it's a traditional JWT and not a JWT. Is there a way in GraphQL to say by default, no one can see anything and then to make it more of like a like an opt-in kind of setup yeah exactly so it depends on how you're building a graphql api right so with hasura when you're building a graphql api that's exactly the

experience that we have right we're like here are all the 10 data sources that you've connected and especially in an enterprise environment right like here are the thousands of models that you have now when you start that experience of building your graphical api you start like creating domain models that are views of these models that you have right and then you start selectively bringing up those models and say that yep this is a part of my api this is a part of my api this is a part of my API. Then you then decide to take a subset of that, the right set of that, transformations of that or whatever, that then become your domain models, right? That actually help somebody who's building a product

understand what this domain is about. Yeah, I mean, it's a really interesting thing because my experience with GraphQL has been where there hasn't been this synergy. And so what you end up with is a GraphQL model and then one or more databases, and they're not congruent. So it's like if someone comes in saying,

hey, I want Tanmai's bank account, there's a certain structure that they're providing from the mobile or from the website. And then I, as the sort of front end, back end developer, have to translate that structure into the database structure and say, oh, okay, actually, you know, in this GraphQL request, there's users and users have bank balances. But in my database, there's actually banks and banks have users. And so I have to manually do this. And it becomes very, very painful to have this sort of like dual understanding of the data at all times. And that's exactly what the modeling layer has to solve for you, right? It's like you should be able to, that decoupling, but keeping it cohesive, right?

That's the work that you need to do with this modeling layer, which, you know, people call semantic modeling or semantic layer or whatever it is, right? But that's like essentially your model layer that describes your domain and maps it to the underlying physical sources that you have. Yeah, but I mean, with something like this, you could have database views. And the database view is nice because it's very descriptive. It's like, okay, I have a table of banks. I have a bank table with user accounts in it, but I'm going to create a view called user bank. And the view inverts that relationship. And then now my API is literally just authorized windows into that view. And now you have full traceability. There's not like Joe who mapped it from A to B in his head. And now Joe quit to join company X, right? Yeah, that's exactly it. And what we do at the Hasura level

is that we make it easy for you to create these database views by creating those views in Hasura instead of having to create them in the database. So what happens oftentimes, especially in enterprise environments, is that you don't actually own the database because people are kind of scared to say that,

oh, somebody's going to come in here and do ddr on my database and create a new table or create a new view so they they sometimes don't want you to have that footprint on the database because it's really important it's like if the database goes down it's screwed right like you're going to lose data you're going to lose like it's it's serious so what you do instead is you create a view at the hasura layer um and so you can create the same view at the Hasura layer, and then Hasura kind of pretends that this is a table. So when Hasura is compiling their GraphQL query

into an underlying SQL query, Hasura is essentially like a just-in-time compiler. It takes a GraphQL query, it does a bunch of things, it understands the authorization rules, it compiles it into a SQL query. Like if you're fetching user banks, for example, it would be like a select star from user bank where

id equal to current session.id. So it adds that where clause essentially, right? Because that's what your policy had. But it's not select star from user bank, it's select star from complicated logical model view, right? So when we're creating, so we're compiling it into the right thing

that reflects what your data sources have. And then, of course, because it's GraphQL, what you can also do is create relationships between models. So you can say, cool, I got this user bank model here, but user bank has city and city has weather. So I want to add weather to this user bank information, but the weather comes from an external API. So what Hasura allows you to do is create a relationship and says, user bank has .city and.city is connected to the weather service. So weather, because weather service exposes weather per city. And so now you can enrich that model. So now from a GraphQL point of view, you're getting user bank and then you're getting.city weather in one query. And these two

models are connected. And Hasura is doing that work of figuring out, all right, you have a model here, you have a model here. This is a relationship. We'll do the work for you to figure out how to cache, compile, query, whatever, right? And that becomes very useful. Because again, you're just authorizing weather data. You're authorizing user bank information.

You're creating semantic models. You're creating relationships. This is the work you want to do. And you get an API. Very, very cool. Oh, you know, one thing we should talk about is definitely like, you know, there's a Hasura platform. Let's say folks want to use just vanilla GraphQL to get started. So someone might have a REST API. They might have a simple website they built, a REST API, a Node.js backend.

And they say, oh, I think this GraphQL thing is perfect for me. How would you recommend people learn about GraphQL and then port REST apps over? What's your advice there? I'm sure you've done it a lot, have a lot of experience there. Yeah, yeah. There's a bunch of things you can do. So I would recommend, so there's a bunch of learning resources that lots of that the community maintains so we have a bunch of open source tutorials that we maintain at hustler.io slash learn where you can go and kind of start playing around with GraphQL and getting a sense of what GraphQL is like if it's going to be a good API for you and stuff like that that gets you started in like a under

a minute basically I think if you're building your own GraphQL API that is mapping to REST API services you have a bunch of options. So there's a bunch of frameworks that are kind of helping you convert REST APIs into GraphQL natively, especially if you have an open API specification that you can convert. So Hustler does that.

You can kind of bring in a REST API, create a GraphQL type for it and get a GraphQL API. The other way, if you want to just like write that GraphQL server code yourself and get a feel for what it to just write that GraphQL server code yourself and get a feel for what it takes to build a GraphQL server, and once you do that, you'll never want to do it again because it's like

a lot of work. It's good to do it, but you probably don't want to do it continuously. It's similar to building a SQL server. Nobody builds servers that speak SQL because there's a query that comes in, you parse the query and you create a query plan

and you optimize it, right? And you do all this work and then you're like, actually, I don't want to, I'll buy a database. Yeah, like compiling your own kernel or something. I mean, you know. Right, right. So you don't do, yeah, you typically want to kind of not do that work,

but it's worth kind of doing that just to get a feel for it, right? and i think that depending on whatever programming language you're familiar with by the way patrick is twitching right now as soon as i said compiling your own kernel is something you never want to do i saw patrick's eyebrow go up patrick is the so just to give you some background time patrick's like a embedded software engineer of the two and i uh my code looks terrible by comparison. Yeah. And he's like, why are people so scared of compiling their own cards?

You do it for me, right? I do it for breakfast, then I do it for brunch. You don't write compilers for your compilers that compile your code to code? Exactly. Right? But yeah, I think to your point, you know, GraphQL, like using like Apollo directly or something is good to do a couple of

times, but yeah, like for example, if you're using Node.js, Apollo has a bunch of libraries and there's a bunch of others, but you can do it. Like GraphQL has GraphQL Java, .NET has,

I think chocolate, it's called hot chocolate. Every programming language has a bunch of frameworks, but I think once you do it once or twice, you will just be like i i know let's use a thing that helps us because i want a graphql api the experience um and i already have these sources of data maybe they rest maybe they're like sad services legacy their services databases whatever it is and i'd like a graphql api so that's typically kind of the curve that we see as well, right?

We see a lot of people kind of like using GraphQL and then running into like performance and observability issues and then kind of saying that, ah, okay, I would like to like automate this layer because I like GraphQL, but the building of the GraphQL is a little bit painful. That makes sense.

So with something like Hasura, that's kind of end to end, how do you deal with transactions, right? So if I need to execute a handful of mutations and roll back if it doesn't work, I know that, I mean, if I was writing this by hand, I would have a GraphQL mutation, and that mutation would have a ton of business logic

that all is wrapped around a session, you know, commit. Yeah. How do you handle stuff like that? Yeah. Yeah. So we do two things, right? So it depends.

For example, if your, if your transactions are simple, we support transactions over GraphQL itself. So you can run a sequence of mutations and they'll all be all or nothing. So it'll all be like a sequence of like, you can do create, create, create, read, update, delete, whatever. And it's a sequence and you can execute that sequence in an all or nothing kind of way. This works only if each of those models are independently secured. It doesn't work if the transaction as a concept

is centralized logic that can't be controlled, like a bank transaction. Even if you secure each of the models inside, like accounts and transactions, you still can't allow a device to run that transaction from a user device. It has to be the user saying, run this transaction for me, and that code has to run in a centralized security context. So what we do for those are we allow users to have two common patterns. The first pattern is an event-driven pattern. So what we do is, I don't know if you're familiar with CQRS

or CQS as a pattern, basically command and query segregation, right? No, I haven't heard of that. Oh, so CQS, CQR is a common pattern for like building and designing microservices and scaling them, where the idea is that you have a read model. So you have models that you can read from, and then you have something called a command model. And so the command model does is that the user provides an input. The input is a command. And then that command then is an event that fires off a transaction

that needs to run, that goes and does a bunch of things and updates a bunch of models and data models. And then you can read from the models that you've updated so so what hasura does in this context is it's like a firm submission right so somebody says hey i want to do a bank transaction so that input comes to hasura hasura validates the input of the command is valid right meaning that it's a user a creating it it's an integer number less than whatever some validation rules right um and then hustler just hands that off to a workflow system a transactional system an http serverless function a stored procedure inside an oracle database

whatever it is we don't care we hand that off to something that runs your centralized logic, right? So we take care of the API contract that's coming in from the edge, and then we hand it off to some centralized logic and we support a bunch that can run. And we do it over events so that it scales easily. That centralized logic does whatever it needs to do. And then when the output kind of comes to us, we then enrich that output back into GraphQL. So you can say, do a bank transaction and the output contains a reference to the account, and you can do a GraphQL query on the account. So you can fetch the account information and whatever has been updated. So this CQRS pattern is kind of what Hasura allows for. What we want

to do is not interfere with business logic on either side. So we don't want to interfere with product business logic or centralized logic. So we just take care of the API contract and then you write your logic however you want to write your logic. But you write your logic without caring about GraphQL. You write your logic just caring about what data systems you have. That makes sense. In complex enterprise environments especially what we see is your one mutation that has all the transaction logic also doesn't scale. Because what ends up happening is that this transaction is often a workflow across multiple services, right? When you don't even get transaction semantics, where what you need to do is do something like create user is like create user as a transaction on database one, send email, initialize data, right?

Like it's like three different services that you need to hit. And so what people end up doing for that is they prefer a workflow engine to orchestrate across these services. And so then what Hustler helps you do is say, hey, we got the input for you and we validated it. And now as this workflow runs,

you can actually subscribe to real-time updates on that workflow. So we often see this pattern, It's called a mutation subscription pair. So you send a mutation and then you get a workflow ID response and then you subscribe to that workflow ID. And then you'll see those updates coming in as your transaction executes across this workflow. And that's what you see in like, you know, like a DoorDash when you're placing an order, right? Like you're seeing that kind of experience. So that's what hustler does does that make sense yeah that totally makes sense yeah no it's a fantastic description i think uh yeah i think it's a

really good way of putting it basically if it's something relatively small like then it literally is a transaction that executes in in kind of one round trip then you have ways to do that but then to your point you know most of the time you have these transactions, there's either a human in the loop or if there's not, there's an external system in the loop. And so you don't really want to just block until it's all done. What you really want is to just say, this is out the door and I'll tell you. And basically things are inconsistent until you know we're done so so you might say yeah you might say like go and spend all my money in my bank account they say okay we're

working on it and maybe you know for that moment you still have money in your bank account and then and but but that's that's kind of to be expected because you know the user experience is like this isn't going to happen you happen in a microsecond. This is like a long running thing. Exactly. Exactly. Right. And there's like all of the API issues are also often at this layer.

Right. So one of the common patterns here that becomes a pain is scaling rights is always a challenge. Right. Because when you have a high volume of rights, like how do you scale that? And so what people typically do is they buffer it. So what you do is, suddenly we had a spike of 1 million events. 1 million writes happened. So you don't actually try to make your database do 1 million transactions because it can't.

And so what you do instead is you grab these 1 million events and you buffer them into a queue. And then the queue then outputs them at a throttled rate that your database can handle right so you tell people that yep i've gotten your order and i've gotten your transaction request and we're processing it give us a set so you queue it up and you let the transactions happen over time and the end user gets real-time visibility into like what's happening right they're like yep it's still processing or whatever. And then when it kind of finishes or it gets taken up for processing, that's when the user gets to know.

So those kinds of things start happening, and that's what the Hustler layer does. Because that's the reason why everybody's saying that you want to have event-based systems. You want to have event-driven systems. This is the idea because a monolithic system can't scale. Yeah, like even as we speak, as we speak, they're still trying to liquidate NFT tokens. It's been going for about six months now,

24 hours a day, seven days a week. And they're still trying to sell those NFT tokens. It's queued up. Yeah, it's still in the queue oh man um no this is awesome so let's let's uh talk a little bit about hasura we talked about you know some things it can do let's talk a little bit about you know in terms of of folks who are just getting started is there a free tier your high school students college students we have a lot of those folks listening to podcasts can they can they use Hasura for free? You know, how does that work?

Yep, there's a free tier on our managed service, it's open source as well. So download the Docker image and start playing around with it. And there's a pretty generous free tier on our cloud service as well. So you don't need to download a Docker image and run it if you don't want to. We've partnered with Neon on the Postgres side as well. So that means that you have free tier Postgres as well. So, you know, you can log into Hasura, create like a free tier Postgres and start actually building the API.

And I think within a few minutes, you'll realize that you've probably saved like writing a week worth of code because you're just creating models and getting an API. So that's one of the easiest ways to get started. Very, very cool. And as far as Hasura, the company,

where are you all based? Is it a remote-first company? Or if it's not, where are the offices? And what's it kind of like over there? We're about 150 people spread across five continents. But we're kind of centered mostly around our hq is san francisco so we have folks in the bay area and then we have another uh centered bangalore in

india and that's another hub so these are kind of the two hubs um and that's where most people are but then otherwise we're also fairly remote so assuming ant Antarctica is out, and what is the sixth continent? Do you not have anyone in Australia or Africa? I feel like it could go either way. No, actually, hold on. I think we're now in sixth then. North America, South America, Asia, Africa, Australia. Yeah, yeah, Europe.

Yeah, that's true. Wow, six. You just need to have. Yeah, that's true. Wow, six. You just need to have someone in that South Pole office. Yeah, exactly, right? I mean, it's just a matter of time. Yeah, that's right. No, that is very cool. Are you all looking to hire?

Is it full-time interns? We are. We're always hiring. And so you'll see it on hustler.io slash jobs or hustler.io slash careers um or just follow linkedin as well and we're often hiring we hire folks at all levels across a variety of roles uh product engineering uh go-to market which is marketing sales uh all of our roles are pretty technical and so especially if you, you know, come from

a technical background or want to enter technology, you're a developer and you want to build something for developers, that kind of thing is what we basically run on. And so keep an eye out on that and follow LinkedIn. And we hire full time folks, we hire interns as well. And so just kind of watch out for that. Cool cool what's the what's the best way for people to get sort of noticed i think it's if you depends on what role you're applying for but we really like it when you have experience with uh the domain and the product so if you build something with hasuro and you know if it's like even if it's a toy application or it's a serious application or you build it at work or something like that, that's,

you know, you just having that context is phenomenal for us. And whenever we see in our applications that people have kind of used Hasura or have experience with it or have, or even in adjacent domains, right? Like for example, the database domain or the mobile web domain or the GraphQL domain and have touched upon or built adjacent concepts that Hasura has built on, that's always great for us. So, you know, the way that you showcase that could be through a portfolio, a website, it could be through an application that you built, could be through a technical blog that you have. So, you know, just having a profile and especially if that profile is immediately relevant or adjacent to what Hasura does, that's always very helpful for us to understand you and your application and process

that faster. Yeah, that makes sense. Very cool. This is absolutely phenomenal. I wanted to ask you kind of a, you know, one thing that we have on the show is we have a book of the show. And when we're doing interviews, we love to ask our interviewer, what is their favorite book? Now, I know you haven't watched every episode. If you recommend a book we've already recommended, that's totally fine. But what is a book that you recommend, especially folks getting started in tech or people who are interested in GraphQL, or it doesn't have to be super technical. What's a book you'd recommend to people with that mindset? I would say when it comes to kind of technology,

like GraphQL-like things, the best way is to just do. And so finding resources that are close to, like if you're like a Python developer, finding something that is close to the Python ecosystem and building that out and then kind of branching out from there is what I found to be the most useful.

And so I don't think I've ever read like a technology book since university. No, sure. But like, what's a book that, you know, just for people who have that mindset, it could be,

you know, there's a, there's a book called the hard thing about hard things. I think that's what it's called, but it's a book. it's Ben Horowitz. Yeah. So just what's a book that, you know, that kind of audience would appreciate that you've read recently or that you are really fond of? I think a little more on kind of perhaps the leadership side of things. A book that I've really enjoyed, I think is perhaps the best book on like business strategy that I've read is a book called Good Strategy, Bad Strategy, which is a short book. It's I think the only book on strategy that has actually made sense and is actionable and

concrete. I've heard about this book. I haven't read it, but you're the nth person to recommend it to me. So this is definitely i'm gonna have to check it out yes it's amazing it's a really nice lead and i think you can apply it at all levels of anytime you need to rely anytime you feel like you want a strategy around something right especially with a team right so so it becomes really helpful for all of that and and surprising because most books on strategy are useful during peacetime and not wartime. So peacetime, wartime is like, I think it's from the Ben Horowitz, Hard Things About Hard Things. Right, right.

It's like description of peacetime, wartime, right? So most strategy books are very like peacetime descriptions of like, oh, everything's going along well and you need to improve something. And so let's create a strategy around it or whatever. But I found good strategy, by strategy to be really good even like we need to get something done in three months or we'll die or you know you need to do something over four years and it's a big transformation that's going to take time so that's a book i've really really enjoyed very very cool yeah it looks like the author is richard rumley i don't know if that's french or if it's rumlet but uh yeah very cool yeah we'll put it

in the show notes and folks can check it out thanks a lot for suggesting that i think it's uh i've heard many good things about that book so uh it's a short book which is nice yeah totally yeah it looks like let me see if i can get the page count here say oh it says uh it's 11 hours on audio which is yeah pretty pretty oh here we go. So yeah, it's not bad at all. You could knock that out in a weekend. Cool. This was amazing. I think we covered GraphQL in great depth. I'm a huge GraphQL fan. I think, you know, I have seen in previous companies, people accidentally expose things in GraphQL because it is so powerful. And that is always something to be concerned of,

which is why, again, having some kind of authorization, as we talked about, is extremely important. But provided you get that right, it's one of these things that becomes more and more important as you go along. And so if you start off on the right foot, it's much easier to keep running. It's much harder when you have, you know, 300 REST calls and, you know, 40 different clients to have to move over to GraphQL. So it's good to learn these things, you know, off the bat. You know, I love how we kind of dovetailed into, you know, how do we connect the model into this database? Really phenomenal. And thank you so much, Tanmay, for having the time to spend with us here today likewise it was a super fun conversation

and uh you know for folks as well feel free to reach out to me if you want to chat about data or graphql or apis and product stuff so i'm always around yeah definitely we'll put it out in the notes but just uh to put in this show do you have a particular way that you like to be reached out to is it twitter linkedin it does it does better okay very cool yeah we'll put it in the show notes so if you're listening on just about any podcast app you should be able to swipe right and unlike getting like a tinder girlfriend or something you'll actually get the show notes and you can go and click on a twitter handle you can click on the programming throwdown page you get the notes in html You can also support the show on Patreon,

which we really appreciate. We take all of the donations from the show and we use it to improve the show and also bring new people. We've brought a lot of new folks into Programming Throwdown and it's just so great. There's actually an email we got, Patrick and I got today from somebody who learned C++ for the first time is just getting started. And that always kind of fills our cup, warms our spirit. So we really appreciate that. And appreciate you, Tadmai, for coming on this show. And look forward to catching up in the future. Likewise.

Thanks for having me. Music by Eric Barndollar. Programming Throwdown is distributed under a Creative Commons Attribution Share Alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide an attribution to Patrick and I and share alike in kind.