Guest: Tanmai Gopal (LinkedIn, Twitter)
Company: Hasura (Twitter)
Show: Let’s Talk

Hasura is an open-source cloud infrastructure solution aiming to make data access simpler for modern application developers. According to Tanmai Gopal, CEO of Hasura, “The idea is that you have one or more data sources and the amount of data is increasing. You want to make sure that the data is accessible to developers who are building applications, or maybe developers in other teams or organizations, and they need access to this data.”

Instead of having to hire a team for this, with Hasura you spin up a container, point it to your data source, do a bit of configuration, set up some metadata, and you’ll have a secure, flexible, GraphQL API that your developers or data consumers can use to interact with the data.

Hasura recently announced a new Data Hub. Commenting on this new service, Gopal says, “Increasingly what’s happening is that some parts of your data, some systems of record, some sources of truth, some business objects are in different SaaS services.” Gopal continues, “What we’ve done is put together a declarative transformation engine that makes it possible to map really easily.” This transformation engine makes it so that you don’t have to write code to map that REST endpoint or that REST resource into something that is kind of native and feels like GraphQL. Gopal explains, “And now all of these REST APIs can be brought into the Hasura ecosystem to your Hasura-powered API through these kinds of transformations. We’re calling that the data hub.”

One reason Hasura chose to go the GraphQL route over REST, according to Gopal was, “Because now, instead of making five different API calls, 10 different API calls, I make one API call and I send the payload.” It also helps that GraphQL offers “faster integration, faster browsing, faster API exploration, built-in metadata.”

As to the trends in the GraphQL/REST space, Gopal indicates, “Unstructured data, structured data, JSON data is exploding.” Gopal adds, “You’re seeing, with serverless functions and with mobile web applications that are closer to the edge that are closer to the user, that experience is becoming really, really good from a developer’s point of view.”

The summary of the show is written by Jack Wallen

[expander_maker]

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to another episode TFiR: Let’s Talk. And today we have with us Tanmai Gopal, CEO of Hasura. Tanmai, it’s great to have you on the show.

Tanmai Gopal: Thanks for having me, Swapnil. It’s nice to meet you all.

Swapnil Bhartiya: We have covered Hasura earlier, but just to refresh memories of our viewers, could you tell us what is Hasura all about?

Tanmai Gopal: Hasura is an open source cloud infrastructure solution. It’s aim to make the data access simpler for modern application developers. The idea is that you have one or more data sources and increasingly the amount of data is increasing. And now you want to make sure that that data’s accessible to developers who are building applications, or maybe developers in other teams or organizations, and they need access to this data. They need to interact with this data. Now, typically when you have kind of this kind of situation, what you would do is you’d staff up a team, you’d build an API service to make that data access possible. What Hasura does is, Hasura automates that. So you spin a Hasura of container up. You pointed to your data sources, you do a little bit of configuration, set up some metadata, and you now have the secure, flexible GraphQL API that your application developers or data consumers can start using to interact with data.

Swapnil Bhartiya: Excellent. Now let’s talk about something which is newsworthy. You folks announced a new data hub, which is kind of a bidirectional REST API connector, and you are also, [inaudible 00:01:25] support for Google cloud. I want to talk about this, and I also want to talk about your whole approach towards REST and GraphQL. But before we go there, tell us about data hub. What is it? What are you trying to do here?

Tanmai Gopal: Yeah. So what we kind of noticed, right, was that with a lot of our enterprise customers and also customers who are just, users who are just building new applications, right. What’s happening is that your data is no longer in just kind of one place. It’s no longer than just say one database or powered by one service, increasingly what’s happening is that some parts of your data, some systems of record, some sources of truth, some business objects are in different SaaS services, right? For example, you might have a new application that you’re building and you’re using Stripe, you have payment data, right? That’s kind of your source of truth for a whole kind of all these business objects in your domain that deal with users and cards and stuff like that. That’s all inside, say Stripe, right. Or in an enterprise, it might be inside SAP.

It might even be inside legacy existing services that you have inside the organization, right. Their data services. And it’s kind of maybe fronting a mainframe application from a decade ago, right. So when this kind of situation arises and you kind of want to bring the unified API for your data, you want to have unified GraphQL API for your customers, this bridging the gap to kind of bring in those existing REST API endpoints and resources becomes painful and challenging, right? You have to write your own code. You have to kind of put that together. So what we’ve kind of put together is this ability is a transformation engine inside Hasura, so that you don’t have to write code to map that REST endpoint or that REST resource into something that is kind of native and feels like GraphQL, right? Like you want to bring it into the GraphOL world. It usually takes a lot of effort. What we’ve done is we’ve kind of put together a declarative transformation kind of engine that makes it possible to map it really easily, right.

Now, once we kind of put that together, what we started doing is started working inside with the community with Hasura people, with our vendors to build these transformations, for vendor services, right. So we’re starting to, we’re working with kind of search vendors, like Elastic and Algolia and [Fauna 00:03:40], Contentful CMS providers like [inaudible 00:03:40], right. All these kind of different CMS providers, different search data providers, even kind of business objects where you’re looking at SAP, S3, Salesforce, Stripe, right. And now all of these REST APIs can be brought into the Hasura ecos to your Hasura kind of API or Hasura powered API through these kind of transformations. So the community effort that we’re putting together and putting all these transformations together, we’re calling that the data hub, right. And that’s going to be kind of a shared effort, a community effort between Hasura, the community members, Hasura users, and these kind of different SaaS and API vendors.

Swapnil Bhartiya: Excellent. Now, thanks for explaining that. Now let’s talk about, I mean, it’s been discussed a lot, a lot has been written on it, but I want to hear your thoughts on REST versus GraphQL. What are the benefits? What value does GraphQL bring to a kind of, full stack developers that REST doesn’t and let’s try to just stay and keep things at technical level.

Tanmai Gopal: That sounds… That’s very good, right. So I think when you think about GraphQL versus REST, right? The important thing is to just take a step back and just look at the evolution of kind of where it came from. Right? So the idea was that when we look at REST APIs and [inaudible 00:04:54] JSON APIs, they’re nice APIs. They’re great. There’s an endpoint. It gives you JSON, right? Like you’re making, it’s pretty clear what you’re doing. There’s different methods. And if you have some documentation along with the REST endpoint, which is a little bit painful, because sometimes it’s not documented well, right. Or it’s out of date, but it’s fair. It’s decent. It’s good to use, it’s human readable, right. What started happening was that as kind of, we started getting more and more API endpoints, right? The burden for the application developer to integrate all of these various API endpoints into their application that started becoming really painful, right?

Imagine that you have an app and you’re trying to show the user, their last 10 orders, their recent addresses and stuff like that. You’re making lots of different API calls to fetch that information, right. And this is a painful exercise, right? So when we kind of think of a more intuitive way to get this information, that’s kind of where GraphQL started to come together, right. And that’s why it’s become popular for API consumers. Because now, instead of making five different API calls, 10 different API calls, I make one API call and I send the payload that I send in the API is what is called a GraphQl query. So I send my GraphQL query to the HDP endpoint. The GraphQL server looks at my query and says, “Okay, you want users, you want ID name, email. You don’t want a hundred attributes. You want only these three, cool. What else do you want about the user? You want transactions”, whatnot, etc, etc.

So look, the GraphQL server understands what you want from that GraphQL query goes out, fetches that data, right? And brings that together in that shape that you want and then sends it out to in JSON, right. So that’s saving a lot of integration headache, a lot of multiple API calls kind of work that you need to do, right. So this is kind of where GraphQL came in and this is why GraphQL is kind of so popular, the tooling around it. It’s a nice type schema. You don’t have to have type documentation. And somebody says that this thing is a true or a false, you expect it to be Boolean, but maybe it’s a string called true or false, and that’s a headache for somebody who’s integrating, right.

So GraphQL came in and kind of got popular and people started really liking it for doing that. Now, when we think of the ecosystem going forward and your question REST versus GraphQL, REST and GraphQL, what’s the story? How do we even think about it? Right. And my answer to that is, we don’t have to stress out about converting all of our REST APIs into the GraphQL APIs, right? We don’t have to worry about it. We don’t have to like do it tomorrow or otherwise we’re going to be outdated and our APIs are useless, right? It’s not that, right. The question is, where is the ROI going to be maximum for getting that API experience out? Right. And you notice that is kind of going to, it’s going to be in a few interesting scenarios.

It’s going to be in a scenario where you have a front-end application that needs to be developed quickly. You want to give a lot of freedom to the front-end application developers to go build those applications fast. So there you notice that there’s a massive ROI to giving them a GraphQL API versus giving them REST API. They’re going be very, like productivity levels are going to be very different. So there’s, that’s kind of one kind of use case where you’re like, “Hmm. The benefit of GraphQL is clear.” If building a GraphQL API is easy, that GraphQL benefit is clear. The other place that you’ll see a GraphQL benefit that we’re starting to see is wherever there are data APIs. So wherever you realize, there’s a lot of your API is essentially dealing with the data that you have.

And there’s a lot of data that’s, like thousands of data models. They’re interconnected. You want flexible APIs. You want [inaudible 00:08:17], filtering, sorting, aggregations, right? You need a flexible API. You realize that the REST style approach is too static. I’m going to have to create one API endpoint for every model, for every type of method I want, I’m going to have to create an API endpoint. Too much effort. GraphQL becomes a really nice data API, right? So these are kind of two scenarios where that benefit of GraphQL is 10 X, right. In other places, exercise kind of caution and thought, right? Think about it. You’re like, “Am I going to get the ROI of having this unified API? Or what is it going to be like?”

Swapnil Bhartiya: Right. This is a question which is more about people side or cultural side of it. A lot of, and this is kind of, I’m just going to talk about REST versus GraphQL as well, which is more or less like, as new paradigms, new technologies, new way of, new processes come into picture. The developers or DevOps depending on how you, or who you want to call them. Their pipelines are already busy. A lot of things are now getting in a developer’s bucket. As much as we talk about your moving every shift left, everything is secured. Everything is moving there. And cloud native is already very, very complicated space. So as much as you know, it’s that we should embrace all these new practices, new paradigms, new technologies, but we should also make sure that the developers life, they don’t get complicated easy too. So can you talk about how is Hasura approaching that? So that while you do tell people, “Hey, you know what, embrace GraphQL over”, but you don’t make their life, kind of challenging as well.

Tanmai Gopal: Yeah, no, thanks. That’s a really, really good question. And I think the way that we think about it, Hasura is very straightforward, right? We’re like, when we look at a technology like GraphQL, it’s new because it’s new. Like you said, it has a huge kind of secondary impact, not just in the developers using or building GraphQL, but on everything else, right. On security, DevOps, Ops, CICD, your process is monitoring, right? Analytics, everything is affected downstream from that, right? So the way that we approach it to Hasura is like, we say that GraphQL is very, very useful and valuable for the API consumer, the people who are consuming a GraphQL API, for them, there is an easy 10 X increase in value compared to using a REST API. Their experience is at least one order of [inaudible 00:10:44] better, right?

Faster integration, faster browsing, faster API exploration, built in metadata. It’s amazing, right? The experience is amazing, but building a GraphQL API, connecting it to these kind of downstream system that we talked about, right, security, monitoring, tracing, telemetry, all of that is hard.

So the approach that we’ve taken at Hasura saying, “If we’ll do GraphQL as a service, you take Hasura, you connect it to your databases, connect it to your REST API endpoints, connect it to other things that you have, right. Connect it to other data sources, connect it to other services. Hasura will become the GraphQL API for you. And then Hasura will connect to all of these downstream systems that are a part of your enterprise that are part of your tech stack. And Hasura will just do that integration, right. We’ll connect with the APM vendors, we’ll connect with the latest and greatest in tracing, right. We’ll make sure that it’s cloud native, right. And it’s the experience of both operating it and using it as cloud native. And we’ll give you GraphQL as a service”, right?

So that way you get the benefit of this new technology, right, in this new experience, but you don’t have to pay that upfront cost of investing time, energy, resources, training into building auto GraphQL server.

Tanmai Gopal: Yeah. That’s a good question. So there’s two angles here, right? One is kind of, when you think about, one thing that is important for people is to give them optionality and make sure that people are not locked in, right. And now in that GraphQL and Hasura context, the way that we approach that problem is fairly straightforward, right? The first is when we are kind of adding that API value, right? The API value on top of people’s data, the important thing is that it’s your data. We are not taking ownership of the data. We are not the persistence layer, right. We’re making sure that those data belongs to you, that data is in the favorite places, your favorite places to store data, right. Maybe because where you want to, or maybe because that’s where it has to be. And you don’t have a choice, doesn’t matter, right? Your data is yours.

So now this is the first level of optionality where we telling our users and our users like Hasura, because they’re like, “Hey, ultimately, this data is mine.” That’s great. That’s awesome. That means that I can use Hasura, but in case I think Hasura is in my stack and I need to switch out of Hasura, I can always move to something else, right. And I can change. I can change my stack and I can change this front part of my stack. It’s decoupled from my database, my data layer. And I can go use, I can build something myself. I can use another vendor or I can do things like that, right. That’s kind of one angle to it. The second is when we think about creating this project, right, and it’s an open source project and there’s kind of a managed cloud version of it, right? There’s an enterprise version of it. Thinking about that difference between what is open source and what is commercial is also really important because you have to build trust to the community, right, that you are not going to lock them in, right.

And that comes from the fact that when we look at our API design, that the API that Hasura provides, the metadata that Hasura takes, right, these are forever going to be in the open source version. And they’re incompatible across our open source and commercial versions. So this kind of builds confidence for people to say that, “Sure. Even though Hasura is kind of providing an API to me, it is an open source and if I go, it is in the Hasura open source project, right. And if I switch out to Hasura commercial or, and switch back, I know that my developers will not be affected. I know that my applications will not be affected, right. So I have that kind of, I’m not locked in to that experience”, right.

So that I think has been also very important. And the third piece of it, which is kind of, I think just to, for which is happening across the industry is we are getting kind of open interfaces and open standards, right. So GraphQL is a specification, it’s created by the GraphQL foundation maintained by the GraphQL foundation. We’re one of the founding members of the GraphQL foundation. And that spec is governed by a foundation, right. So that means that ultimately that GraphQL specification is not proprietary, right. It’s being maintained by a foundation. And that means that there’s a thriving community around it. They’re also building GraphQL services. So you’re not locked into one GraphQL vendor, right. So that’s kind of the way we think about it.

Swapnil Bhartiya: So one more question that I’ll ask and if you want, you can bring in this point as well, which is, so, I mean, with every new technology, we start building things around it and we start investing resources. We start moving users to that technology. So from app development delivery  is GraphQL the future, or do you feel that this is kind of placeholder for all something new and shiny will come? First of all, none of us can predict, but will be next Kubernetes, right. But what are your thoughts on this?

Tanmai Gopal: I think GraphQL for application development is definitely kind of the future. It’s going to take some time for all of us to move to it, but it’s definitely the future in terms of that kind of experience, right? So unless something that is better than the GraphQL, better than the experience of using GraphQL comes in, it’s going to be hard to kind of displace GraphQL and GraphQL is a simple but valuable technology, a valuable technology enhancement that we have seen, right. So I think GraphQL is in that sense the future for application developers. And the nice thing is that it’s incremental, right. Moving from an application developer’s point of view, moving to GraphQL, like consuming a GraphQL API from consuming a REST API. It’s not a big shift, right. It’s incremental. It’s easy to move to that. So from an application developer’s point of view, you don’t have to freak out, right. So that’s there.

Swapnil Bhartiya: In addition to this, what kind of trends are you seeing in the space in terms of either GraphQL or REST or other technologies?

Tanmai Gopal: That’s a very good question. I’d say that two broad trends, right, that I’m seeing kind of in the industry that are sort of complimentary to this motion that we are seeing with GraphQL as well. One is kind of on the data side. And the second is I think on the application side. So on the data side, we’re seeing this trend where we have more and more databases, we have more and more specialized databases, right? So you have databases that are specialized for analytics, time series, search transactions, distributed transactions, right. Unstructured data, structured data, JSON data, right. So that is exploding. It’s increasing continuously, cloud vendors are creating kind of proprietary solutions, the open source communities innovating, there’s lots of database vendors that are innovating. So I think there’s a tremendous kind of amazing trend that’s happening there, where people are now creating the persistence layer and the data layer that is going to scale to the workloads of the future and is optimized for a particular kind of domain model, right? Like, you know that your domain model is a time series model, so you have a time series database.

You know that your domain model is a transactional model, you have a transaction database. You know that the domain model here is a search model, you have a search optimized database, right. So I think that is, the bridging of the gap between a domain model to a data model, right, which is what database is were supposed to do, but they couldn’t keep up, right. We are now in that generation where the databases are kind of coming in bridging that gap. And they’re keeping up with the kind of demands that we have for modern applications in terms of scalability, in terms of it being cloud native and reliable, right. So I think that’s a amazing trend that has happened that now kind of allows us to become more productive and stop worrying about like, how do we operate this database and how will we run it? And like, will it scale, right?

So you’re moving away from those operational concerns to productivity concerns, where you like, “Let’s get our model in and it’ll work”, right. On the second side, this amazing trend that I’m also seeing is on the application development side, where we’re seeing a [inaudible 00:19:04] edge, we’re seeing application development becoming easier and easier day by day, right? Especially the Java script ecosystem, mobile web ecosystem, and also kind of like the edge ecosystem, right. You’re seeing with serverless functions and with mobile web applications that are closer to the edge that are closer to the user, that experience is becoming really, really good from a developer’s point of view, right? Developers don’t have to think about infrastructure and Ops. They can just write code. They can write code that is adding the value to the end user in a way that makes them as productive as possible.

There’s lots of different kinds of frameworks that are optimized for different kinds of use cases, which is great because that fragmentation helps you build for a particular use case. It helps you build much faster. And also because of the innovations that are happening in the way that we are hosting applications, in the way that we are running serverless functions like application logic, right, the way we are sharing application logic between the edge and the device, right. I think all of that is amazing because it’s kind of helping people build scalable applications just from the [inaudible 00:20:02], right. They just write code, they iterate on code quickly, they’re releasing several times a day, right. And it’s all scaling to those use cases. So I think those are kind of two broad trends that I’m seeing in kind of the application development ecosystem.

Swapnil Bhartiya: Tanmai, thank you so much for taking time out today. And of course, talk about Hasura. We have covered the company. So thanks for just refreshing your memories, but more importantly, talk about this whole REST API versus GraphQL, the value it brings and what Hasura is doing to actually helped developers make things easier for them. So [inaudible 00:20:36] takes for the work that you’re doing, but also thanks for joining me today and share those insights. So thank you.

Tanmai Gopal: Thanks for having me, Swapnil.

[/expander_maker]