Tanmai Gopal:
Users were so happy that we were on Discord helping them that they started helping each other. You just genuinely want to help people and the community and if you can channel that energy and that authenticity, it'll just happen.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open-source projects and the communities that make them. I'm Eric Anderson.

Eric Anderson:
We are live today with Tanmai Gopal of Hasura and this is a conversation I've been looking forward to for some time. One, because Tanmai is a wonderful person and I'm sure I'll enjoy it, but also because Hasura is an exceptional project worth spending some time discussing. Thanks for coming, Tanmai.

Tanmai Gopal:
Thanks a lot for having me Eric and hello to all the listeners.

Eric Anderson:
We could start on so many things, but let's do our usual and have you ground us in what Hasura GraphQL engine is.

Tanmai Gopal:
Yeah. So Hasura is a data access engine and what that essentially means is that we aim to replace the traditional three-tier stack that you have with the API gateway, the app store or in the ORM that is usually required for you to build applications. And we want to replace that with a neat little box called Hasura so that people who are building modern applications, they can focus on data and logic and not be bothered by anything else that is an infrastructural concern while building or operating and that's where Hasura fits in. And so the idea is that if you're building an application and you want to leverage existing data, what you do is you fire Hasura up as a container or on a cloud, wherever.

Tanmai Gopal:
And you point that to your data sources and Hasura has a nifty UI or JSON thing and you configure that and you say, "Hey, these are the data sources I want to bring in. These are their relationships within that data source or across data sources and these are the authorization rules." The authorization rules are critical. That's where you usually build your own APIs to absorb that part of the business logic. And as soon as you set that configuration up, you have a production-ready GraphQL API. In fact, we have support for REST as well. And so you have this API that's good to go. And the dream of having self-serve access to data so that you can go ahead and build stuff is unlocked so effectively, you're compressing nearly three quarters of worth of time into maybe a week or so. And it's a magical experience. What I really feel happy about is developers and the community users are just like, "It's just magical." I love hearing that.

Eric Anderson:
You do do a lot. You mentioned the authorization, you mentioned connecting to existing sources. Perhaps I'm naive, but some of the things that first jumped out to me was giving GraphQL on Postgres felt like a place where people are like, "Oh, I know what that is and I want it." And I'm sure there's a whole bunch more it, but I imagine that's a part of it.

Tanmai Gopal:
That's the emotion that you get started with. You're like, "I want to build this application and I want to build this with the latest and greatest stack. I want to make my front-end with whatever is the new JavaScript framework today." And I don't mean that in a bad way. I love the JavaScript ecosystem and the base at which it's evolving because it's just a sign of maturing in the industry that you have a framework for every damn use-case. You have this brilliant stack and you're ready to go, or you want to use serverless functions because you just want write code and have it work and have it scale and not worry about it. And you want to do this, but you just can't because you're like, "Crap, this data is inside." We started off with Postgres and now we have SQL Server and we did BigQuery and MySQL and Oracle and stuff like that.

Tanmai Gopal:
And you're like, "But this data is just in my database. How do I get it out? And there's a bunch of stuff that I need to do in the middle to actually get that out in a high-quality way." So that's where it all starts. It starts with this urge to say, "I need access to this so that I can build stuff." And that's where Hasura sneaks in and the idea is that it takes you a few seconds or a few minutes to really just get started with that experience. And you instantly feel like weeks melt away when you're clicking on a button and just getting your API. And then you start configuring it because you need to set up authorization and all of the other things that you need to do to make that data access piece work.

Eric Anderson:
Totally. Great. Given that, let's also figure out how we got here. We've talked over the years so I know part of the story and it fascinates me, but how did you get started on this journey?

Tanmai Gopal:
Yeah. It's a trip down memory lane. It started off with me and my co-founder and my co-team. We kind of banded together with this abstract idea and this feeling that application development is just way too complicated and with just 20, 30 million developers to date, the world needs 100s of millions of developers. That is the future, that is where this lands up, but there's missing abstractions, there's missing components in the infrastructure that make it painful for us to get from here to there. To get to this future where application development is at the speed of thought. And to do that, we had this hypothesis that there's this piece that people spend a tremendous amount of time with, which is this data access piece. And it was a little bit out there.

Tanmai Gopal:
And so what we did was we started a consulting firm and we started building this data access layer. We built a bunch of other components as well. And we started working with everybody from the largest banks in the world to the smallest startups, to an old company building it's first digital asset, companies of all kinds, engineers of all kinds. And we started using this product in the work that we did. And this was around the whole time that the Docker or Kubernetes movement was happening. We were early adopters there and whatnot. So we were seeing that cloud native transformation happen and the role of this piece in that cloud native transformation. And the API that we'd built at that time was our version of GraphQL so we kind of invented our own GraphQL. It looks almost exactly like GraphQL, but a JSON form of GraphQL so if you're familiar with GraphQL you have query and then curly brace and users, curly brace, ID and name so you specify what you want. Our query language was type, select, fields, user, nested ID. It was like a JSON version of the GraphQL query.

Eric Anderson:
Yeah. You totally invented GraphQL in parallel.

Tanmai Gopal:
Yeah. So we did this in parallel. And then I remember before we decided to wind down the consulting firm and take the GraphQL engine out and raise money and launch the product and stuff like that to the community, I remember in 2016, we looked at GraphQL and we looked at the spec and we were like, "Nah, this is never going to take off. This is hard. Who will ever build a GraphQL? How will you use this? There's so much cost to putting it together." And then when it started picking up and this coincided with the time that we decided to build the company around Hasura, we decided to use GraphQL because as an intent and as a specification, it absorbed exactly the value that we wanted to give to people which is self-serve access to data over an API. You want a self-serve API. And GraphQL embodies that intent like nothing else that we've seen before. It's just shamelessly geared towards making it easier for humans to explore that API by themselves, explore the API and then dig in themselves.

Tanmai Gopal:
And so we added support for GraphQL in 2018. That's when we launched the open-source project. And then it really clicked with the community. I think in the first year we went from zero to two million downloads, the second year we went to 2 million downloads. And we started seeing a lot of good mission-critical traction into large companies as well, which was nice and which then set the foundation for starting our commercial offerings. So that's how it came together.

Eric Anderson:
Wow. Tell me about the team formation. So these were people you had worked with before, or you kind of came together at the consulting firm?

Tanmai Gopal:
The early team, the core team came together at the consulting firm. So it was me and my co-founder who started the consulting firm. I came from a machine learning, computer vision background, I had done my bachelor's and master's and I wanted to unsubscribe from the ML and the AI. I was like, "I cannot, I just cannot. It's amazing, it's great, but I feel like there's some more systemic problems that I want to really work on that is closer to the metal." I'm more of a systems person at heart and then I wanted to start doing this thing. And my co-founder at the time was going through a similar journey. She came from a computational biology background. She did some research work for a while. Her work from then just got published in Nature, like a year ago or whatever.

Tanmai Gopal:
And then she was just getting frustrated with the research and she was like, "What is happening? Great, we can do biofuel with algae, but I do not want to do this for 10, 15 years because I don't know if this will see the light of day." And then got connected and then we started working on stuff together and Hasura came out of that. And the other members in the core team were folks that I knew from university, folks that I had worked with in university before and one of my juniors from university as well. So that was the core team that got together, that became the founding team at Hasura as well.

Eric Anderson:
And we could spend some time on this I imagine. How do you find your initial users? The magic behind Hasura is in part, not just the technology, but the community building.

Tanmai Gopal:
That makes sense. It's almost like a chicken and egg thing. You have a product first, but then I need the community and then I need users. We were confident that we were solving a really painful problem. We would take away a lot of ground work that people were doing. And we were confident about that because we were our own users. From there, the exercise became, "We have the product and we know that it works. How do we start getting the community around it?" And I remember before we launched and while we were adding the GraphQL API in addition to our API, we talked to almost everybody in the GraphQL ecosystem at the time. And we did demos with them. And we were like, "Hey, this is what it does."

Tanmai Gopal:
And then we heard it back from them. We were like, "What did they get from this demo?" And from our list of 20 things that we wanted to talk about in the product, that we thought were cool, we took that down to a small list of things, things that we thought were awesome but people were like, "Eh". And then other things where people were like, "Well, this is amazing." And we were like, "Hmm, we never thought about it." And so we started putting that together. And then after we open-sourced it, we started putting the word out. One of the moments was when it got traction on Hacker News, a lot of things get that traction on Hacker News initially but the question then becomes how do you sustain that?

Tanmai Gopal:
And so after we did that, my co-founder, who heads our community marketing efforts, she was just absolutely nonstop about making sure that we can keep talking about the same things that people liked and keep putting it out there because it's resonating with people, it is resonating with people. We need to keep driving that so that it's top of mind for enough people to get to a critical mass. The way I think about it is that if a hundred people look at your product, one of them... How do people see that your product is cool? One of them will actually bother trying it out this weekend when they have some time. And then out of a hundred people who try it out, only one of them is going to be a social media person who recommends it to other people. Most of us developers are not hanging out 24/7 in conferences and on social media and on Reddit and screaming from the rooftops, "This is the tool I use." You don't do that, but some people do and they're very connected in the community and they talk about it.

Tanmai Gopal:
So getting that conversion from hearing about it, it is a problem that I want to solve, that I want to get solved to trying it out. And then from trying it out to having such a good experience that if somebody asks you about it, or you feel like evangelizing and talking about it. You're like, "Hey, I just tried this. It was amazingly cool. What do you think?" So getting that critical mass going was the most important thing. And we were just absolutely brutal about that getting started experience. We were like we care about nothing else but from the time that you click on the get started button on Hasura, you're like, "I look at the top folder, I go to GitHub, I look at the repo and the first thing I should see is a way to get started."

Tanmai Gopal:
And from that point to getting your first GraphQL query, there should be no extra concepts that come to you. We don't want to introduce any nouns to you, any concepts to you. We call it nouns, right? There's an informal thing of saying that, "Are you trying to add a new noun to the product? You do not add nouns for the product." I was like, "Nouns are bad." It also fits in well with the fact that we are a functional shop, so objects or bugs are bad. We were like, "Nouns are bad, get rid of any noun." No concepts that the developer or the person that's trying it to needs to be introduced to do till they just get to that first GraphQL API.

Tanmai Gopal:
And so enough people got that, people started talking about it. And then of course we were very diligent about making sure that we're putting out enough to the community in a way that they want to consume this information, that it builds enough critical mass. And then once that critical mass builds up, the second phase of this was... We did kind of the opposite of sometimes what the popular wisdom is that don't talk to all of your users directly in the late stages. You don't want to do that because there's just too many people. But what we did was we opened up every single line of communication there was with everybody. Our entire-

Eric Anderson:
Radical transparency.

Tanmai Gopal:
Yeah, just radical transparency. And we were just helping our users of all types all the time on our Discord. And we were just at it continuously. It was really important for us because some of these early engineering leaders who are not PMs, they were just continuously exposed to feedback from users. And we were also understanding different types of use-cases, what people are building. Why are they building it this way? Why did they come this way? So we would pick those insights and then within a few days, we would react to those insights and say, "Okay, here is a very pressing use-case. We should really talk about this." And then we talk about this and it resonates with more people. So that had a lot of good secondary effects because we use that knowledge, not just for improving the product and the experience and prioritizing that roadmap really aggressively in the early days but then also building a culture of community in the company all the way from the engineer, to me as the CEO to everybody.

Tanmai Gopal:
And that had a really good impact because a year after that, a few months after that even, that became like a flywheel because users were so happy that we were on Discord and helping them, that they started helping each other. And then it became a community where, although we still hang on Discord most of the times, most questions as they come up, get answered by our people in the community. And we're like, "Well, this is cool. This is nice." So the short answer to that is just a tremendous amount of work and love for users. You just genuinely want to help people and the community. And if you can channel that energy into that authenticity, it'll just happen. I always feel that it's hard to fake add-on community as a hack. We're like, "Oh, we use the community to grow." Sure, that's maybe the end result of what you're doing, but it's really hard to channel the right energies to do that well. It doesn't feel authentic to anybody, to you or to the community.

Eric Anderson:
Were there any critical pieces of content? It sounds like it was generally user love and lots of little steps over time. I remember three-factor app seemed quite popular. Were there any kind of things that really accelerated things?

Tanmai Gopal:
Not really. I think there were lots of small spikes. The three-factor app thing really did very well in absorbing that idea. And we're going to do an overhaul and a re-launch of that this year in the next few months. But people really bought into that idea. They were like, "Hmm, this makes a lot of sense. I don't want to have this app somewhere in the middle, I just want data and logic and I want to get down with it." And so a lot of times when we saw those kinds of use-cases from the community that seemed like it was a group of people, what we would do is we would take that and then we would do really good content around it to help people who have that use-case and we would try to distribute that in development communities.

Tanmai Gopal:
So when there were new frameworks popping out on the front-end side of things, when there was all different kinds of Postgres use cases that people had, because we were the only people doing geolocation, queries and we were the only people doing subscriptions in real-time at the time. So we would use a lot of those niche use-cases to help spread the word. It's kind of ironic that sometimes the most mainstream use-case is not what you want to talk about because it gets lost. So what you want to talk about is the niche use-case that only a few people are excited about, but they're so excited that they help spread the word. And then eventually, maybe not too many people use it for the niche use-case.

Eric Anderson:
I'm always Googling new frameworks and niche technologies as part of my job. And I used to tell people that I run into DigitalOcean all the time. They're always creating content around X, Y, Z thing. And now I'm running into Hasura all the time. It's like I want the next JS app and I want to do X, Y, Z on it. Here's an Hasura thing. There's that GraphQL-

Tanmai Gopal:
GQLS.

Eric Anderson:
GQLS framework and Hasura has got the first result on how to use it. And so I think there's some real power to that kind of attacking niches.

Tanmai Gopal:
Exactly. Because all those niches represent an intent. And that intent is really powerful even if that particular use case may not be the same. So it becomes very useful to spread the word. The other thing that also really helped was we have a very kind of, if I may say so myself in lack of humility here a little bit, there's a lot of really good engineering in the product. And so we made this consistent effort to keep talking about the internals and the engineering and some of the engineering choices that we made. And that also resonated with people. That would also frequently get people talking about us. Even today because of some of the early work that we did... I like to say that we started the performance awards with GraphQL, before we came along, nobody was talking about performance and we were like, "Oh, this is just 5X faster or 50X faster, 100X faster than whatever you would do." And that's obviously exciting to people because it's performance.

Tanmai Gopal:
But then you can't talk about the engineering of how we did that, how we made that happen, how we took an approach that was inspired more by compilers and databases on the app server rather than approaches that are popular on the applications that we're building. And that got us a lot of good community engagement. That was very positive as well, despite the fact that we build in Haskell, which is a niche language. So that's...

Eric Anderson:
Despite that headwind. Yeah. Let's talk about conferences for a bit, because I think five years ago, had you built this wonderful open-source community, you would have imagined building a flagship in-person conference at some expo hall. And COVID came, it may have been a problem for you, but at the same time, I think you've helped define how maybe conferences are done in the future. Tell me about how you approach conferences, events I should call them.

Tanmai Gopal:
Yeah. That's a very good question. I think Rajoshi, my co-founder, she's built a really good team of people who can just execute really well. And again, that culture of community and wanting to do something for the community and having them genuinely involved and making people feel good, that energy that the core team has, and now is kind of company culture I think, really helped. So that allowed us to transition quite seamlessly into the COVID world where in fact, we were able to do much more than what we would have done if we were offline. We started reducing the conference size and we changed the formats a little bit. We tried to make it as engaging for people as possible without it being like a drag on your time. Having good kind of content from the community, from strong other people that we invite and stuff like that.

Tanmai Gopal:
That's also had a really good impact both for us on the company and the product front, but also for the community. So we do GraphQL Asia, which we started many years ago, which is now actually GraphQL Global or whatever, but we didn't want to change the word so the last two years, we've just been calling it GraphQL Asia. And then we did the Hasura Con, which is our user conference. We did the first edition of that last year, which amazing success for us. Your first user conference you're always a little bit nervous, you're like, "How many users will come? What did will they talk about?" And it was just spectacular because all of our mission-critical users really came and talked about how they were using Hasura and what they learned, what doesn't work, what works.

Tanmai Gopal:
It was a good knowledge-sharing thing for the community. And then the enterprise GraphQL Con which we did. It's not too heavy for us to organize a conference now, a small conference is very easy. We have a good community of people, we know who's interested in what and so we we're able to gradually amplify that so it's been much easier than trying to do it in the real world. That would suck. You have to figure out a venue, get a lot of people in, logistics and nobody actually cares too much about it. They're like, "Well, we want to just meet people and talk to them." So that works out well in the online world.

Eric Anderson:
Yeah. A glimpse into the future. This is what events will look like going forward.

Tanmai Gopal:
This is what it should be. When I was in school in university, I would think about like, "Why are we traveling to places? Why don't we have Starbucks cafes with a wall that's just a VC wall and a video conferencing wall and then you sit on this side and somebody else is in Starbucks in a different city and you're having a coffee together?" That should be the reality. Why are we even traveling? I'm hoping this happens now, hoping we'll all unsubscribe from traveling. Let's just talk online.

Eric Anderson:
Yes. We'll cancel all travel.

Tanmai Gopal:
Exactly.

Eric Anderson:
Random other topic for you. I ran into one of your users and we were talking about the benefits of Hasura. And this person said, "I think what the Hasura team may not realize is that the secret sauce is in user-authorization." They were like, "We went for the ease of setup and taking out the toil between setting up our back-ends but we're staying and we're hooked because of the authorization framework." Is that representative?

Tanmai Gopal:
Yeah, it is. It is very true. It's also a very deliberate choice for us that was almost an accident of history. So when we started building our authorization layer... What our authorization layer essentially does, it says API call comes in, but this API call obviously can't access all elements of data because if I'm a bank user on my app and I'm accessing my account balance, I should see my account balance. And there might be many complex conditions that determine that accessibility like, "Am I blocked right now? Am I a free tier? Is this my account, account.user ID equal to me? Or account.managers contains current user ID." There's lots of conditions that determine their accessibility. Usually, people write code to do this. We just made it a declarative condition of the graph.

Tanmai Gopal:
So in that graph of data that you have, can you specify a condition that determines whether this entity is accessible or not? And then we combine that into the data fetch query and that's how it works. Now, the reason that we built this... And the system is very similar to RLS or Row-level Security that you see in advanced databases. I built the first version of our GraphQL engine on of Mongo before Hasura started. And then our lead engineer and architect came and he's like, "Oh, what the hell is this? Please switch this out and we're going to replace this with Postgres." So he removed all of my code. He re-wrote the whole thing to work with Postgres. And at the time, Postgres did not support RLS. And we were like, "Okay, cool. We'll build RLS. That's the model that we want at the application level."

Tanmai Gopal:
And at that time, we knew that it would be very useful to build the RLS at the application layer, it was a deliberate choice. But in the interest of building things, we might not have done that, we might have just used Postgres RLS had it been out because then it could have worked. But then once we did that, the amount of power that we could unlock by owning authorization for all of your data systems, by having that in one central place, became extremely powerful. And this control of this authorization system and providing value for authorization is beyond massive because it's not just this first element of accessing data and having authorization to it.

Tanmai Gopal:
The authorization of data is the most critical aspect to solving problems like caching. So if you think about one of the last complex infrastructure problems to solve, it probably would be caching. And this is hard. This is hard because you fetch restaurants on your app, I fetch restaurants on my app, but I'm in a different city, you're in a different city, even though the API call is the same, we're fetching different pieces of data because we're different people. Our identities are different, our authorization rules are different. So the system can not cache automatically because it's the same API call, but how can I cache it? The same API call made by different people is different results. But because Hasura has that authorization engine built in, Hasura can understand that this is a group of people, the cache key is city.

Tanmai Gopal:
And because the cache key is city, Hasura can start caching automatically. We've already done this and we've really seen great success with some users and we really started talking about it towards the end of the year. But this is going to be massive for people because they're just going to be like, "Oh, API caching is solved. I don't have to do this by hand anymore, this cache key determination, maintaining this cache key, LRU, whatever, whatever, I don't care about it. I just want it to cache wherever it should cache." And so that authorization engine is a very, very powerful piece to have. And I'm happy that users are feeling that because that's where the heart of Hasura is.

Eric Anderson:
Awesome. Another topic for you, my GraphQL experience has been such that the first thing I'm attracted to is the API, the JSON-like. But then you discover this whole world of federation and stitching. And I feel like that may have been the bigger idea at Facebook that for me, didn't catch on until later. Help me understand the role. You started mostly on GraphQL for Postgres, but I feel like you're moving into a broader story of just GraphQL for all the things. And I imagine part of that's federation and stitching.

Tanmai Gopal:
Yeah. That's a very topical topic for everybody in the GraphQL ecosystem. So slightly contrary to what you said, the use-case for GraphQL at Facebook was very different for the rest of the word, because Facebook is a very unique engineering company. It's not a product that is a pattern. It's very weird. It is extremely high concentration of technical talent and extremely rapid growth, unprecedented rapid growth, which is very different from most engineering products and especially products that already exist because they're already there, there's already all of this engineering there. So when GraphQL came to Facebook, it was really a very logical evolution for them. They had a monolith, they had one monolith and they had an internal API for that monolith that their apps were using.

Tanmai Gopal:
And they were like, "Well, this API consumption is shitty for several reasons. We should just have something that does it as a spec, which is much better." And that's how GraphQL started. There was no federation, there was no fetching from multiple data sources. It was a different API on top of that would integrate value over the existing business logic stuff that they already had. Their data systems are behind that [tier 00:28:00] which are very, very different again from anything that the rest of the word uses. I think they rebuilt everything. They built their own programming language on PHP and whatever. So it was very different. But for the rest of the world, everybody uses microservices for better or worse because organizational complexity is hard. There's a lot of different products. The reality of it is that it's just easier if everybody just owns their own domains and does stuff. In this context is kind of where this idea of federation or stitching comes in and where GraphQL has a potential play here.

Tanmai Gopal:
But I feel it's slightly broken promises because what happens is that when people try to use GraphQL as just that API gateway layer that is just fronting multiple services, I think it's fine but the ROI is not enough. Because what happens is that you're introducing another operational complexity. Somebody has to build a GraphQL layer, somebody should connect them together, somebody has to maintain it as an extra network hub. This GraphQL API gateway doesn't play well with anything else in the API ecosystem. It doesn't do caching, it doesn't do security, there's no monitoring, there's not error codes. What happens to alloting when API goes down? The most popular GraphQL specification implementation is that you keep it running to hundreds.

Tanmai Gopal:
So all of that tooling just goes out the window. For what? So that people could build front-end apps faster. Now that ROI justification is going to be valid for very few people. For most people, that's not going to work out. And so that's the API gateway piece on it where you want to stitch in these different things. But the most dominant use-case there is, there is one product that needs to speak to multiple services and multiple services got built for some reason and one product needs an entry point into these multiple services. Now this is not where a tremendous amount of ROI might come from, there is some ROI there, but it's restricted only to front-end applications and it's restricted only in the places where you want a back and forth, like a BFF. That kind of layer.

Tanmai Gopal:
Where we see the GraphQL federation being a lot more potent is for a polyglot data and in a sense, polyglot logic as well which is what is happening. You have different data services, IO databases or SaaS services, which are essentially databases in a way. Like Salesforce and Stripe is a database with methods and returns data to you when API calls. So you have these data sources and whoever does building this, needs these data sources to have schematic relationships and solve certain problems to get access to that. And now you might use this for a variety of things. You might use this for building front-end applications, for somebody building something else. That's kind of the use-case that we think about a little more. There's a heavy overlap but we think about that use-case a little more to basically empower this idea of saying that you're getting data from wherever you want.

Tanmai Gopal:
So there's different places where you can do this federation and stitching at different layers and that's one point. The other small point is that sometimes it becomes a little bit of a buzzword where you're like, "Oh, I want to have a unified graph across my enterprise." Now, any enterprise person worth their salt who's done this work will realize that having a single unified graph across the entire enterprise is the worst possible idea. Imagine you are a, not like a product Silicon Valley company but you're just normal people building normal applications in enterprise or whatever. And those environments, what happens is that you have hundreds of LOEs, hundreds of lines of business. You do not want to have an unified graph because if you give one application team the full graph of the enterprise, they would lose their mind.

Tanmai Gopal:
They would be like, "What is... I do not want the unified graph. Please give me the three end-points that I want. That's all I want. Do not give me the 1 million." So the reason why you want the unified graph and what the unified graph is, becomes really important. You can't just arbitrarily go in and say, "Let's mix all the things together." That's the nuance there. Very roundabout way of answering your question, but there we go. Those are my two minutes on federation and stitching, I guess.

Eric Anderson:
Great. We have a few more minutes. What haven't we covered Tanmai and if not, we can just go into where the project's headed from here and how folks can get involved if they haven't already.

Tanmai Gopal:
In terms of folks getting started, please just head to hasura.io and then head to the docks and see a bunch of different ways of getting started. If you're looking at just playing around with Hasura and getting a feel for the product, Hasura cloud is a fairly seamless experience. In just a few clicks, you should be up and running. If you prefer local development or you have a database that you're running locally or somewhere, just download the docker image, run that and you should be good to go in a few minutes as well. In terms of where the project is going, more data sources that we're integrating with. We did Postgres, SQL server, BigQuery, which was our first OLAP foray and MySQL. And we'll be looking at document databases towards the end of the year, and then a few more other relation databases in the meantime. Very excited about a few very interesting use-cases that we're working on with some of the users at the largest possible scale where they're moving from single Postgres to distributed Postgres and how Hasura is making that transition seamless for them.

Tanmai Gopal:
I think for a lot of people, it's going to be an amazing use-case to understand that, "Hey I can start off with this and then I can scale to read or write storage with tens of millions of concurrent requests or users coming in." and stuff like that. So I think there's a lot of exciting stuff there. Towards the end of the year, we're going to start launching a lot of caching type use-cases that we talked about and it's like the CDN, but for your GraphQL APIs in a way. So we start talking a lot more about that. There's a lot of very interesting stuff that's happening for users there. So that's roughly what's in store for the rest of the year.

Eric Anderson:
Fantastic. I remember and I had a question, but any comments on the Hasura logo? I remember when I first started, you had a mascot that I thought was endearing. You've since professionalized a bit.

Tanmai Gopal:
Enterprised a little bit. Yes, this is true.

Eric Anderson:
That's right.

Tanmai Gopal:
It's true. Yeah. You don't like growing up sometimes, but you just got to grow up a little bit. Hasura word itself comes from a common south Asian root word called Hasura, which is like a demon, but not like a demon as a bad demon. Demons are just another class of divine beings. In fact, in a lot of places in Asia, east Asia, Southeast Asia, you'll see these demon faces, which are like faces with big eyes and horns and tongue sticking out that people use outside their doors, you'll see them on trucks that people that have to ward off evil.

Eric Anderson:
Yeah. Almost a protection thing.

Tanmai Gopal:
Yeah, exactly. Protection thing. It's more like ward off evil. You even see it on a lot of Hindu, Buddhist temples where you'll see demons on the temples and the site. It's very popular, kind of original meme from millennia, I guess. And we were punning on demons, like server-side processes are demons and we were Haskell so we said Hasura or whatever. So we decided to use that as our mascot. But then it was hard to draw. It was more like an image rather than like a logo. And well, for some people in enterprise, they were like, "What is this?" And I'm like, "No, no, no, focus on the GraphQL, don't worry about this piece." But then we were like, "Okay. You know what? Let's just go a little more black and white. We'll still try to keep a little bit of our character." And so now we have that logo that has kind of gentle horns and then a lambda in the center. And so that's fine. We're still carrying that legacy forward a little bit.

Eric Anderson:
Yeah. Very good. Congratulations. Tanmai, you've done amazing work, you and your team. It's great to have the input today and how it all came together. Thanks for coming on.

Tanmai Gopal:
Thanks a lot for having me, Eric.

Eric Anderson:
You can find today's show notes and past episodes at contributor.fyi. Until next time, I'm Eric Anderson and this has been Contributor.