Ep. #35, GraphQL Querying with Hasura’s Tanmai Gopal

Brian Douglas: Welcome to another installment of JAMstack Radio. In the house we've got Tanmai Gopal.

Tanmai Gopal: Hi folks, I'm Tanmai and I'm one of the founders at Hasura, we do GraphQL for Postgres.

Brian: Cool. Let's start there. What is Hasura? What problems are you guys solving?

Tanmai: Absolutely. The core of the product is that we help teams start getting productive with GraphQL super-fast, especially the real time GraphQL because real time GraphQL is a little hard to do.

Brian: What you mean by real time GraphQL?

Tanmai: GraphQL subscriptions or life queries. You want to build an application that's reacting real time to things that's happening in the back end. We provide that API layer and we create that API layer automatically on top of an existing database or a new database. Today we have Postgres, eventually we'll have other databases as well, but that's what the product does.

The aim is to help people get productive with the CRUD and the real time part of GraphQL. Typically if you look at an application a bunch of it is CRUDdy or needs real time, the other bunch of it has business logic implications. We want to help people with the CRUD and the real time portion of it so that you can delegate that part to Hasura, and then you can do the rest in your favorite GraphQL framework however you want to write it.

Brian: When you say Postgres specifically, why Postgres? Is it Postgres only? Do you have to have your own database to use with Hasura?

Tanmai: Today it's only Postgres and you need to own your own database. Hasura is an open source service, so you run that open source service in front of the database wherever you have your database. You can have it on RDS, on Heroku, on your laptop, on prem, wherever. Our users deploy all over the place and then you have Hasura sitting in front of that talking to the database. Why Postgres? Because Postgres is the best database.

Brian: OK.

Tanmai: There is no other database. Postgres is a good general purpose application database. If you're starting to build an application today one of the best choices that you could make is Postgres. That's one. There is also a strategic implication to using Postgres, because if you look at a lot of new databases that are being built today, like the non-relational Atlantic scale databases like CockroachDB, there's Cockroach Labs that's building CockroachDB. There's YugaByte, there's TimescaleDB which is a time-series database. There's CitusDB which is like Scale or Postgres. All of these may not be Postgres underneath but they all speak the Postgres protocol.

Brian: Gotcha.

Tanmai: If you had an application that could speak to a Postgres database, you can switch that out and replace that with something else.

Brian: Interesting.

Tanmai: So that works out well.

Brian: You say you're open source protocol, so your entire product is open source?

Tanmai: Completely open source.

Brian: OK. I've got more follow up questions for that, but to talk more about Hasura and how it stands in the middle, what are we--? A lot of the listeners are familiar with Graphcool and Prisma. To use that context, how would you compare against Prisma?

Tanmai: Got it. A little bit of the technology sounds similar. Prisma helps you get GraphQL on top of a database and so do we. But the positioning in the product is different. For example, Prisma is what is traditionally called an ORM. If you're building an application you typically have a front end, a back end and a database. The back end has to talk to the database. Whatever business logic you write has to talk to the database, and that uses an ORM.

If you were using Java you would use the JDBC connector, if you were using [Ruby on] Rails you would have Activerecord, if you were using Python you'd have SQLAlchemy, with node you'll have Sequelize. These are the traditional ORMs, and what Prisma wants to do is replace those ORMs with GraphQL using Prisma. Prisma sits between the database and your business logic, and then your business logic goes through that.

Brian: OK.

Tanmai: We're different. We're more like AppSync, where we're saying, "Write your own GraphQL service just the way you want to. Use Prisma, don't use Prisma, whatever you want to do. But the CRUD in the real time portion of your GraphQL API, that's the bit that we do." What Hasura does is it gives you that GraphQL API on your database, but it gives you access control so that you can-- It's not direct access to your database, but Hasura also does schema stitching.

What you can do is you can have your own GraphQL services, they can be in serverless functions, they can be micro services. They can be done in Java, talking to Oracle, it doesn't matter. You can stitch that together with Hasura schema and then your app can use, "I want CRUD and real time stuff. That's high performance out of the box with Hasura, but I need to make a payment API." That's your business logic. All of that comes together. Does that make sense?

Brian: Yeah. The schema stitching, that sounds pretty valuable for myself. I build on projects for GitHub. That's my base layer, my example apps all start with GitHub for obvious reasons. I work there. Schema stitching is something that is front of mind for myself, but I've never had a good solution for it. I know we've had a lot of the community members in GraphQL provide solutions but they all seem challenging, or maybe scratch a couple check boxes, but it doesn't check a lot of my boxes. I've always been challenged in trying to approach schema stitching. I've given up on it in the last six months, just trying to wait until there's--

Tanmai: A better solution.

Brian: A better solution and something I could just drop in. It sounds like Hasura is--

Tanmai: Trying to give you that experience. Try it out and let me know what you think about it.

Brian: OK, yeah. I wasn't even aware of that feature set. I'll definitely try it out. The reason you're here in SF and we're talking face to face is because you were here for a number of conferences too as well. What conferences have you been at?

Tanmai: I started about three weeks ago speaking at a Postgres conf in San Jose. Then I went to Finland for speaking at GraphQL Finland. That was super fun. Then I came down here for JAMstack Con, I was doing a lightning talk there. I was showing how you can have a Gatsby site that uses Postgres as a data source at build time, and how whenever something changes in the database you can trigger a build on Netlify. That was a super cool exciting demo. It was a 10 minute live demo and it was pretty nerve wracking and super fun. Now I'm attending GraphQL Summit which is tomorrow, or the day after.

Brian: Tomorrow.

Tanmai: We're hosting GraphQL Contributor Days early next week. It's the first edition, we have a bunch of contributors from the GraphQL community, Lee Byron, Uri Goldshtein who has just built a bunch of new tools. Putting everybody together in a room and discussing a few advanced problems with GraphQL or scaling large apps in GraphQL. So, lots of stuff.

Brian: I'll be in attendance. I just RSVP'd for that for next Monday.

Tanmai: Awesome.

Great, I'll see you there.

Brian: One of the organizers reached out to me.

Tanmai: Sweet.

Brian: I'll definitely be there. I look forward to seeing all the talks that you have been giving so far, but I'm curious more about the business aspect of Hasura now too as well. Because you mentioned your open source framework protocol, but I'm not sure what term you use--

Tanmai: The whole service is an open source service.

Brian: Open source service. So you're here in San Francisco for conferences, but also to build a company as well.

Tanmai: Absolutely. On the business side what we're doing is that today we offer support to our users. We have a bunch of users in enterprise who wanted to get started with GraphQL, had existing applications built on Postgres, deployed Hasura on it and got instantly productive, super happy. But now they need a commercial version of the product, because a lot of large companies can't deploy open source products straight up inside. That's a monetization strategy for us immediately in the short term.

But going out a few quarters from now and a year from now, we're looking at adding commercial features to the product and a managed service so that you don't have to host it yourself. You don't have to operate or scale Hasura yourself, we run it in your Cloud VPC, in your cluster or on the Cloud, whatever it is. We'll ops that for you so that you don't have to ops it. We're adding a bunch of those features over the next year. I don't want to let too many cats out of the bag, but that's the rough plan.

Brian: That sounds interesting, and I find it intriguing too because I started with GraphQL when it was originally announced. More of tinkering around with it, but by the first GraphQL Summit two years ago, that's when the announcement of GitHub going public-- Or, developer preview. That was my intro into GraphQL, was actually using a real public API. What I'm getting at is it's interesting to see companies build around a new spec, like Postgres has been around for a while, JavaScript development has been around for a while. GraphQL is new, so it's interesting to see newer companies come out and help support the ecosystem. In addition to yourself, some Prisma and Apollo. So I'm curious, how long has Hasura been around? Because I've only heard of it since Reactathon.

Tanmai: Yes. We built the tech out about a year and a few months ago, and we launched the open source service just about three months ago.

Brian: Three months ago? OK. When we first met at the Reactathon--

Tanmai: We were just starting to add support for GraphQL.

Brian: OK.

Tanmai: We were just getting early feedback from users about what they think about GraphQL support. Then we built that out, polished that up, and then launched that.

Brian: That was quick. You already had branding and a logo at that point?

Tanmai: Yeah, we did.

Brian: It's like in high school. I'm not sure how it is in India, but in high school everybody has a garage band, and you spend more time building logos and band merch--

Tanmai: That is always the problem. Logos are a problem, and then naming new modules or new things that you are building is a problem.

It's such a big problem that you can't start writing code because you need to name your folder something.

Brian: Yes.

Tanmai: And then you're like, "What do I call this folder?" Whoever is the first person to name the folder has unofficially named the project.

Brian: Yes.

Tanmai: That has happened. You cannot undo that action.

Brian: For a previous company I worked at, actually Netlify, I would name new projects intentionally bad to see if I could force other people to review the naming structure and convention, and we ended up with going way more generic on naming. We have NetlifyCMS today, and it's a generic name that works. But I threw out a bunch of random names to force the issue, and it's funny because you're solving one of the two hardest problems of programming. One's naming, and then two is N+1 queries. So, hopefully--

Tanmai: Hopefully both those problems are in the bag. N+1 queries is solved, the next one is naming things.

Brian: We now have a name for adding GraphQL to our Postgres.

Tanmai: Absolutely.

Brian: I remember when GraphQL first came out there was another project that was open source--

Tanmai: PostGraphile.

Brian: Is that similar?

Tanmai: They are also fairly similar. They're more similar to us than to Prisma, although on the surface everybody's a GraphQL API in our database. There are a few different approaches though. Benji I'm fairly close with, a good friend of mine who's building PostGraphile. Their approach is that everything comes from Postgres. Your users are defined, your access control functions, everything is defined inside your database and your database is driving the entire API.

Whereas our approach is a little more hybrid. We're saying that a bunch of stuff will come from your database, but a bunch of stuff might not, so we do the schema stitching natively to help you support that. One of the things that we're super excited about, we put this up on Hacker News last week and it went up on the front page, it was good. We call this the three factor app, inspired by Heroku's twelve factor app.

Brian: Yes.

Tanmai: The three factor app is whatever application you build, Hasura, it doesn't matter. But whatever application you build, your back end should have real time GraphQL, and it should have event sourcing, and it should have serverless. The idea is that instead of traditionally building an API where I create an order and then I wait for the API to talk to three other micro services to orchestrate that and say, "Validate order. Make a payment. Check with the restaurant if it's open or not, and then write down the response." Instead of doing that, the approach that you can take is "Create the order. Get an order ID as a response, subscribe to the order ID to see what changes are happening on the app." Because it's real time.

Brian: Yes.

Tanmai: For the user, the user doesn't have to wait. The user has this experience of saying, "Create order. Chuck. Created." And now you have three tick boxes waiting to happen. What's happening on the back end is that instead of your API orchestrating a workflow, you emit events and those events trigger serverless functions. That is super cool because people want to move to serverless, and when people want to move to serverless they need this event system. That's what Hasura does as well, and this is something we added recently.

Most of our users are moving towards that event framework. They're saying "CRUD real time, Hasura, some API schema stitching and as much of my code as possible. Let's put it into the event driven serverless stuff because that can scale. I don't have to worry about it scaling. Emit an event, serverless function comes to life. Emit 10,000 events, 10,000 serverless functions come to life. So that's what we're going after. It's a little different.

Brian: Does Hasura provide interactions with serverless functions as well as deployment strategies as well? Is that part of the--?

Tanmai: Yes. Well, not deployment, but triggering serverless functions. Integration with serverless functions to trigger them. That's what I was demoing at JAMstack Con, I was using Netlify functions which is a nice wrapper on AWS Lambda. That's what we were demoing, we were like "Something changes in the database. Let's trigger a Netlify function and make it do a build for us. You can make it do anything, but in our case let's make it into a build."

Brian: That makes a lot of sense. Netlify really appreciates that with the JAMstack architecture.

Tanmai: Exactly.

Brian: They handle all the static deployments, but to create things real time, they definitely created Netlify functions for your use case, which is great. I'm curious, can we go back in time? I'm curious, what was your introduction to GraphQL? What made you want to start a company, and how did you get introduced to this?

Tanmai: It's a little bit of a convoluted story.

We always had this hypothesis that API development should be far simpler than it currently is.

There's a lot of boring work that you're doing, like CRUD in real time. It's boring. Why is everybody writing those APIs again? Write the smart stuff, write the cool features. Why are you doing this? We always wanted to automate that portion, so what we done a year ago when we first built this and we were just building this out we had JSON APIs. We heard about GraphQL and we were like, "What is this? A new language? I don't need a new language on the client. I have JSON, why would I want GraphQL?"

Then every time we would talk about our JSON APIs, it would sound as if I'm describing a GraphQL API. I'd be like, "Instead of having multiple API endpoints why don't you have one JSON query to fetch exactly what you want?" And then I'm like, "If I replace JSON with GraphQL, that sounds like I'm describing GraphQL." It was our immaturity in not understanding that the key feature, and I did a blog post talking about why you should not build a JSON API and you should build a GraphQL API. The key insight for me was, what's awesome about GraphQL is not the query language. Netflix Falcor has another spec, and they all allow you to fetch data in a single query and avoiding that whole multiple REST query problem, and so did our JSON API.

But the coolest thing about GraphQL and any GraphQL server is introspection. Every GraphQL server-- If I'm a GraphQL sever, you're a GraphQL client, you can query me for data and I'll respond to you with data. But you can also query me for, "What models do you have?" And I tell you the models, and then you can say, "But can you describe this product model for me?" And then I tell you "This product has an ID and a name and a nested brand." That ability makes GraphQL the coolest thing, because that's what's happened in the community. Everybody has built such amazing client side tools. Developers have an amazing experience, imagine the experience that I have an IDE, and in my ID I'm building an Android app and I'm getting an auto complete for my API. That's insane.

That experience for an application developer is amazing because I don't have to go to an excel sheet where there's documentation, or Swagger where there's documentation, or worry about a typo. My ID is giving me that feedback because the community has built tools to use that introspection of the GraphQL server to build cool stuff. You have Apollo clients doing caching for you, you have this ID tooling, you have Ivan at API guru who's built GraphQL Voyager which visualizes your GraphQL API for you. That's what makes GraphQL amazing, it's the ability for GraphQL to spawn community tools like us or anybody around it, and that's something that we did not understand before actually using GraphQL. Once we used GraphQL we were like, "We would be the stupidest people on the planet to have not added GraphQL support."

Brian: Your story is-- We've had quite a few people share their story of how they got into GraphQL. This is not a GraphQL podcast, but we've had quite a few GraphQL stories shared. Coursera comes to mind where they were building their own API introspection tool on top of REST and JSON, and Meteor is another one also. The reason why Apollo exists and that they were so far ahead is because they were already building something that looked like GraphQL. Then they noticed that this spec was slightly better and there was more people attaching themselves to it, so it's cool to see that we now have Contributor Days which is next week, and hopefully future Contributor Days for GraphQL. On my ride over here I saw Lee Byron announce a GraphQL foundation as well. Which is huge.

Tanmai: Absolutely. It's amazing.

Brian: Lee who now is at Robin Hood, he left Facebook but it's important that now we have a foundation so that we can continue to create the tools to help build the community and stuff like that. Speaking of tools, I was working on my talk for this week at GraphQL Summit. I'm going to be giving a talk around improving developer experience using the GitHub GraphQL API, and I joined GitHub 6 months ago. I didn't put much time into GraphQL until the last couple months to prepare for my talk, mainly because I was trying to ramp up and do some other stuff with the API things and I missed out on all the new things that came out in the last 6 months.

The community has overlapped itself and all the things you could do, like now you can add atom plug ins and VSCode plugins to get that auto completion with your queries, which is great. One of my biggest gripes for the GitHub API was when I was using it outside of GraphQL is that all the information for the reference points were all built over the 10 year span of the API being existed. There's a lot of weird, "This endpoint has this data, this format type," but when you go to issues you'll have a whole other format typeset or returns, so you have to plan for all the breaking changes that happened over the past four versions. With GraphQL you don't have to worry about that because they can improve the endpoints without breaking APIs. What's your thoughts on adoption for GraphQL?

Tanmai: Of course I want it to be the biggest thing since sliced bread. Because I'm in it. I have a few data points on this, but replacing a huge chunk of your API with GraphQL is going to happen. It makes a lot of sense. What doesn't make sense to me is replacing 100% of your APIs with GraphQL. I would still do Auth with the REST APIs, just because there's so much good infrastructure around O-Auth2, JWD and stuff like that. I don't want to use that. I don't want to reinvent the wheel for that. Stuff like binary stuff, file uploads, large streaming media uploads. I would rather use the existing APIs, they've solved that problem well. But for the data portion of stuff, I don't mean the database, but I mean the data portion of your app should replace that and will replace that. The very cool thing that I've seen with GraphQL which I've not seen with any other technologies, when GraphQL came out as a spec.

It got immediate adoption in old school enterprises. One of our clients is a Fortune 500 healthcare company who you would not typically associate with modern software or that they're on the bleeding edge, but the adopted GraphQL instantly. The second it came out the architect looked at it and said, "We have a huge problem with our internal platform and people who are building apps internally using these APIs that we have, and we have so much of this documentation problem and people talking to each other. We want GraphQL." Then when we released our high performance GraphQL blog post, they used it, evaluated within weeks and they're on it. That's insane. I work closely with a Fortune 300 bank, and they started using GraphQL two years ago. They bought the first version of the Facebook GraphQL spec and they started using it two years ago. A Fortune 300 bank. That's insane.

Brian: That is pretty awesome.

Tanmai: That's insane. And they've poured in millions of dollars to get that GraphQL layer running internally. It's fairly important for them to have that internal and central platform for doing governance stuff and whatnot, but it was amazing for me to see that kind of adoption for GraphQL.

It means that it's rare that you can have technologies that solve both a process and political problem.

Brian: Yes.

Tanmai: It's rare for that to happen. It's not common. It's common to have, "We have the next big database," "We have the next big thing. We have the next big this." But to have technology that changes the politics of how a team works, that's rare, and it's amazing that we've gotten this far in such a short amount of time. So, GraphQL is going to stay.

Brian: I'm banking on that as well. If someone wants to get started with Hasura, if they have the Postgres app or they're interested, what's a good place to--?

Tanmai: Head to the website. We have a "Try it on Heroku," thing. We're the number one button on Heroku. We're the number one thing that's--

Brian: Really? Congratulations on that.

Tanmai: That's good. I opened up the Heroku ecosystem page late last week and I saw, "Number one is Hasura, above everything else." That was insane. So, that's the fastest experience. You can go to the website, click on "Try it on Heroku." You'll have your Postgres and Hasura provisioned within 30 seconds. Use the UI, make a table and get your GraphQL API instantly. Like within a minute you'll have your first API, your first database.

Brian: Cool. Well Tanmai, Thanks for coming on to talk about Hasura. I'll transition us over to JAM picks, these things are things keeping you going. Food, music picks, technology picks, all the above. Since you're so well prepared would you like to go first as our guest?

Tanmai: Absolutely. So, I'm from all over the country in India. I am technically from the North, I lived in the West and I spent the last decade in the South. My favorite kind of food is a South Indian breakfast. There is nothing in the world that comes close to a South Indian breakfast. If any of you are listening in on this and you have not had a South Indian breakfast, and you want a connoisseurs introduction to it, please hit me up on Twitter and I'll take you to a bunch of places in the Bay Area. We will have a South Indian breakfast.

Brian: You can actually get it here.

Tanmai: Yep. There are a bunch of nice places that have it.

Brian: You'll be here for a while, so I need to hit you up.

Tanmai: Absolutely.

Brian: For sure. Any other picks for us?

Tanmai: If you're reading something, and you want the next book to read and if you're into science fiction, I would highly recommend The Three Body Problem. It's by a Chinese author called Cixin Liu, and it is the most mind expanding book that you will ever read. It's contextualized to the way China sees itself, in the way the space race is evolving. It's amazingly insightful, it's very well-written. Amazing ideas. You should definitely give that a read.

Brian: All right. I've got some picks. My first pick is GraphQL Summit. It's happening this week. By the time this comes out the videos will be on YouTube, check out my talk on the GitHub GraphQL API. Also one of my co-workers will be talking about how to build, or how we built the GitHub GraphQL API. It's the most detailed information to date as far as what GitHub's done. Check that out, and also check out my talk from last year about how if you're interested and you don't have a Postgres API you just have a REST API that you do want to get GraphQL in, I did a lighting talk on working with complicated APIs the same way. I talked about building wrappers and gateways.

Tanmai: Awesome.

Brian: Using and leveraging existing tools like Launchpad, which now you can use serverless functions to do this as well.

Tanmai: Got it.

Brian: Check that out if you're interested. I also have a Reddit that I've been following as of recent, which is Frugal Male Fashion. This Reddit provides awesome tips on things that are on sale and clothing, and I mentioned this because since I live in the Bay Area I've been using Amazon to buy all my t-shirts. Previously the now-forgotten American Apparel, you can get $4 t-shirts American Apparel shirts. So, when I moved here all I did was go to meet ups and collect tech t-shirts, and I realized those are the most comfortable t-shirts. I was like, "I don't want to wear other people's brands but I'll wear the shirt because it's so comfortable.

I started buying them on Amazon for $3 or $4 bucks a pop, and then American Apparel went out of business. I've recently discovered thanks to Frugal Male Fashion that canvas tees, I've been buying a lot of tall tees. They're a little more expensive, ironically because they're not made in America, but they're around $6 or $7 bucks a pop. But it's way cheaper than walking into any store down on Market Street or in the mall or whatever, to buy a shirt that is not worth that amount of money. Anyway, I highly recommend going to Amazon. Go to Frugal Male Fashion on Reddit and improving your fashion, because we all need help around that. That's all I have for picks. Again, Tanmai thanks for coming on.

Tanmai: Thank you.

Brian: Talked about Hasura, GraphQL and the future of GraphQL. Listeners, keep spreading the jam.