Brian: PodRocket is sponsored by LogRocket, a front-end monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Ben: Hey, everyone. Welcome to PodRocket. Today I'm here with Johan Eliasson from Nhost. He is here to talk about backend as a service and the awesome product they're building. Welcome, Johan. Johan Eliasson: Thanks, Ben. Happy to be here. Thank you. Ben: Maybe you could give us a quick introduction about yourself and Nhost? Johan Eliasson: Yeah, sure. I'm a software engineer and an entrepreneur, I usually say. I have one leg in entrepreneurship and one in software engineering. Throughout my career, I think I just combined those two in various places. Yeah. Always building stuff, always have side projects. Always try to learn the latest technologies, and that's one of the reasons why I started Nhost. Nhost is a back-end as a service, so it's an alternative to Firebase. Also open source, but with a GraphQL API. I think a lot of your listeners know about Firebase, so it's an alternative to that. Ben: Yeah. We've done Firebase on the show. We've had Supabase on the show. So, very familiar with this set of tools. I'm curious. It sounds like GraphQL is one of the big differentiators for Nhost. A bit more context, what does the database look like? No SQL, SQL? And then, how does a GraphQL API work? Can you use any client, or do you have client libraries? Curious to hear a bit more about that. Johan Eliasson: Absolutely. The stack you get on Nhost is a Postgres database, so it's a relational SQL database, which was very important for me when we built it. So, it's not an NoSQL database we're using Postgres, and we're using something called Hasura. Hasura have this amazing software. They have this GraphQL engine that sits on top of Postgres and automatically, instantly, generates a GraphQL API for you, based on your tables and your columns and everything that you have in Postgres. Johan Eliasson: They ultimately generate the GraphQL for you. And, it's a real-time GraphQL API, so they're using what's called subscriptions in the GraphQL spec. So, we have the database, we have the GraphQL API layer. We also have authentication, and we have storage, and we have serverless functions. We try to offer all the fundamental building blocks that is required for a developer, or a team of developers, building any application. We provide our customers with these building blocks. We host it for them. We scale it, we secure them. We manage them, so our customers can focus on what's important for their business and for focusing on the product they're building for their customers. Ben: And so, on the frontend, can you use any GraphQL client? Could I use Apollo Client or any GraphQL client for JavaScript that supports subscriptions? Johan Eliasson: Yep. That's correct. You can use any GraphQL client. Where Nhost stops... We handle the back end, and then what you're doing on the front end, you can use any client library. We provide some client libraries to make it easy with authentication and storage. When it comes to GraphQL, there's so much good tooling. As you mentioned, there is the Apollo Client. There is various other clients. There are clients for flutter. Yeah, this is all on the frontend. You can use these other libraries. Ben: When you're designing your backend, are you using... How do things like API security, API authentication, and stuff work? Does it all come out of the box, or do you configure Hasura with this? The normal Hasura API? Johan Eliasson: Yep. Permission is handled by Hasura, inside Hasura. Hasura is not just a GraphQL API. They don't only generate the GraphQL API, but they also have permissions built into it. You create these boolean permissions to make sure that your end users are allowed to insert, update, read, and delete what they should be allowed to do. That is handled by Hasura, and that connects to our authentication module that is tailored to work with Hasura. So, our authentication module generates the correct JWT tokens with the correct claims. So, when you're communicating with your back end via your GraphQL API, Hasura understands who is a user and what are these users allowed to do, and not. Ben: With Hasura, do you do those authentication rules? Is it declarative? I think Firebase has almost like a JSON syntax, where you declare the auth rules for different parts of your tree of data. Or, is it imperative? I'm just curious how Hasura does auth rules. Johan Eliasson: Yeah, for sure. Hasura have this GraphQL engine, as I said, where they're generating the GraphQL API, but they also have a Hasura console. Hasura console is a UI where you can manage your database, and this is also where you can manage and create your permissions. You can select your table, and then you select what users are allowed to do, or not do, on that particular table. It could be something like, "Well, you're only allowed to read this row if your user ID matches a user ID on the table, or in a relational table to that role that you're creating permissions on." You can say that it's a boolean permission system, so you create these boolean rules that either returns "true" or "false", if the permission pass or not. Ben: Does that UI spit out some sort of config file that you can put in version control. I'm curious how people collaborate on rules. Johan Eliasson: Yeah, yeah. That's correct. When you generate these permissions and change anything else in the Hasura console, all metadata are saving to metadata jumble files that you can then virtually control in Git. Same thing goes for the database. When you create a table inside a Hasura console, the correspondent migration files are also generated automatically. If you create a table, you name it something, you create it, automatically, there will be a generator. The generation of migration files for the database will also be there. Ben: Moving on a bit. You mentioned, in addition to database, there's auth, there's storage or serverless. Maybe you could talk about auth. Do you leverage an existing open source auth tool, or is this something you built? How does auth work? What sign in methods do you support? Johan Eliasson: Yep. This goes back to the story, why Nhost started. I found out about Hasura, but Hasura only takes care of the things that we talked about, like the GraphQL layer, and they leave authentication for developers to figure out themselves. You can use Auth0 or any other auth provider that generates the correct JWT tokens. Johan Eliasson: What I did back in... This was 2018. I built an opensource library called Hasura Backend Plus. It takes care of authentication and storage specifically for Hasura, and this is also what we are using with Nhost. I figured, "Well, Hasura is great. Postgres is great. We need to have some way of easily integrating authentication and storage," because usually, that's what you need. A lot of other people needed that as well, and that later became Nhost, because I figured, "Well, now we have all the building blocks. Just make it easy to use." Johan Eliasson: We support email, password. We support the regular auth providers. You can log in with Github, Google. I don't know. Spotify, Steam. All these different providers. We're going to release Magic Link support here in the coming days, so we're adding features to that. Yeah. It's an important piece of our product offering. Ben: Is storage S3-compatible API blob storage? Is that the right way to think about it? Johan Eliasson: We use S3 under the hood, but it's a layer between S3 that also integrates with the Hasura permission, so you can use the same Hasura permissions to make sure the user is allowed or not allowed to upload certain files on certain directories, and then we save everything into an S3 bucket. Internally, we're using MinIO, which is an S3 open source equivalent of AWS S3. Storage, we actually have some quite big changes coming up. We're rethinking the way we're going to use storage, but it's still going to be S3 in the backend with Hasura permissions in between. So, some really cool things coming up there. Ben: Finally, serverless. Any differences in how you think about serverless versus something like Lambda? Johan Eliasson: Yeah. At the moment, we implemented serverless functions, very similar to how Vercel is doing it. You just have your API folder, and you create your folder and file structure that becomes the end points. And, you just have HTTP request handlers, and then you can build anything with TypeScript or Note. Johan Eliasson: Actually, what we have in plan, and what we've built for, is for people to bring their own docker containers to run any HTTP server in any language they'd like. That's an up-and-coming feature. Maybe, we're thinking a little bit different there, but we're starting off by these tools that people are familiar with. I think a lot of people are familiar with the API folder structure of Vercel or Next.js. Ben: Talk to me a bit about hosting. I saw, on your website, you used DigitalOcean, but I'm curious. Do you offer both? A hosted solution and, obviously being open source, folks could self-host. How do your users usually think about that? Johan Eliasson: Yeah. That's correct. Everything is open source, so you can self-host the whole and host a product stack, no problem. What we're providing is a one-click, you get everything up and running in four to five seconds. We're using DigitalOcean at the moment, but we're in the process of actually moving to AWS to support more locations and to support some other cool features that AWS can help us offer, where maybe DigitalOcean is lacking a little bit feature-wise. Johan Eliasson: But mainly, it's because we're rebuilding our own infrastructure, so we thought, "Okay. Might as well move to AWS or some other big provider to support more locations, because we're getting a lot of requests from different locations, and different data laws with Europe and Australia, South Africa." We want to be on those locations, and also, at the same time, provide better scalability. That's what we're working on. Ben: Yeah. I was curious about DigitalOcean, because I feel like it's declined. Maybe this is just my feeling, but I feel like it's declined in popularity in the past couple of years. But, if someone didn't have concerns about geolocation in terms of where they're locating their data, would you recommend DigitalOcean as a good hosting provider for a stack like Nhost? Or, are you finding that it doesn't have the level of features AWS has and it's not worth it for the maybe cheaper pricing or simpler interface? Johan Eliasson: Yeah. No, I think DigitalOcean is a really good service and cloud provider. If you're happy with DigitalOcean or you're starting out, I think definitely DigitalOcean is the place to go. AWS is more mature. They have more locations, but they're also more enterprise-focused, which means you need to know a lot more to get started. But, in terms of scalability in these kind of things, DigitalOcean is perfectly fine if you're happy with their locations. They have good locations, right? They have locations in U.S, Europe and then various other places. They cover a lot of areas. Yeah. Big shout out to DigitalOcean. I think they are great. I've been using them for years. It just so happens that we need more locations. Yeah. That's a big thing, I'd say. Ben: I want to circle back to Firebase and Supabase, which are two competitive tools that come to mind. Maybe starting with Firebase. I'm curious. What's the competitive pitch for why use Nhost instead of Firebase? Johan Eliasson: Yeah. Three things technical wise. Number one is a relational database instead of a NoSQL database. This, I think, is very important. I think people are starting to realize that this is definitely very important for building applications. You can normalize your data. You get data integrity. And, there's all kinds of safety features around using a relational database that you don't get with a NoSQL database. Maybe it's a little bit slower, building proof of concepts, but the advantages that you get with a relational database definitely is worth it. So, relational database. Number two is GraphQL. GraphQL is such a great technology, and it gives frontend engineers superpowers. Frankly, it just makes sense. It was open sourced from Facebook. Johan Eliasson: Everyone is using GraphQL. You have Stripe using GraphQL; you have Airbnb using GraphQL. It's everywhere, in these large corporations. The problem is, it's very hard to build a good GraphQL engine. But now, with something like Hasura which automatically generates it, it's democratized. Now, Indie Hackers can start using GraphQL. That's another piece. Johan Eliasson: The last thing is open source. We're a hundred percent open source, and there's no lock in effect. This, I think, just... What do you say? Rhymes with the community. It's just what developers wants in these times. A fourth thing that I can mention is, we've taken a lot of inspiration of from Vercel and Netlify. How they have their developer experience being super nice. It just makes sense when you're using these services, and they make it so easy. You connect to GitHub repository and everything is connected. We try to do the same, so we also have a Github integration. You can develop locally, and you can push your changes to your repository and we will automatically deploy it. We tried to create the same super nice experience that Netlify and Vercel is doing for the front end. We are trying to do that for the backend. Ben: And then, how about Supabase? Supabase is open source, so it does have that advantage, but curious why Nhost instead of Supabase? Johan Eliasson: I think the GraphQL part is definitely a big one. It just makes sense. You have Postgres on the database. You have type-safety there. Then, you can have GraphQL, also type-safety, and then you have TypeScript running on the frontend. So, you have type-safety through your whole stack with GraphQL, and also, just the way you query it. Yeah. GraphQL is a big one. Otherwise, I think we're very similar, I feel like. Johan Eliasson: Maybe we are pushing it a little bit more on just the experience, how you connect your GitHub repository. Trying to be a little bit like Netlify and Vercel, but both Nhost and Supabase are very early companies, so we'll see what happens there in the coming years. But, I just feel it's so great that there are coming so many good alternatives for frontend engineers. It makes me very happy that frontend engineers have more alternatives. It's not just Firebase, there are these open source tools that they can use as well. Johan Eliasson: Yeah. I'm just very grateful for the tools that enables more frontend engineers to build more cool stuff. Ben: Yeah. I'm curious to hear a bit about the company itself. I know you recently raised a seed round of funding. What was it like to raise money, and any advice for other folks looking to raise money for an open source dev tool project? Johan Eliasson: What was it like? It was a lot of Zoom calls for the last year, which was fine. I mean, I'm in Sweden. My co-founder, he's from Azores, outside Portugal. We've been working remote. He's now in Berlin. I'm still hearing Sweden. Yeah. We're just taking a lot of Zoom calls, talking with investors, and then we clicked with this firm called Nauta Capital. I think they're from Spain, but they have offices in Spain, UK, and Germany. Berlin as well. Johan Eliasson: I think they also saw the big opportunity for someone like Nhost to bring a good open source alternative to the market, and just that there are so many frontend engineers. So many new engineers coming out to the market want to build things, want to have side projects. Building stuff inside the companies that they're working at. We got some amazing angel investors. The co-founders of GitHub are angel investing in Nhost. Co-founders of Netlify is investing in Nhost. Yeah. It's a great group of people. I think all of us believe in the same thing, and that is to empower developers and frontend engineers to build really cool things. I think we're just scratching the surface of what can be built and is going to be built here. Yeah. The future is bright, I'd say. Ben: Yeah. Speaking of future, if you can, anything you can share about your roadmap? What are you most excited about to be building in the next year or so? Johan Eliasson: Yeah. Obviously, our own infrastructure. We have a lot going on there and that's really exciting, because the way we're building it now is going to accommodate for horizontal scaling. Basically, across all services. Also, read replicas in different geographical locations. The way we're building it now will accommodate for some great scaling and onboard a lot of big customers. Yeah. We have a lot of big customers in the pipeline who want to use Nhost, but at the moment, we can't accommodate for that. That's something that I really look forward. At the same time, I'm looking forward to... Johan Eliasson: Maybe we could do a secret announcement here. We're going to launch a freemium version, which we don't have at the moment. You can test it out for 14 days, and then you need to upgrade to our first plan that's only $4 a month. But, we're going to do a freemium version. We really want to go broad and help a lot of developers who want to use Nhost. So that, I'm looking forward to. Yeah. I think those two things are some big ones. Ben: If anyone out there is interested and wants to get involved... I believe you're hiring, right? Should people get in touch with you? Can they contribute open source as well? Johan Eliasson: Yeah. As you say, we have a lot of open source projects, and we have a lot of support from the community, building stuff for us. That's really great and that's really fun to see, and we try to support anyone who wants to help us out on the open source and the community side. Johan Eliasson: Also, we're looking to hire some really good infrastructure engineers and DevOps engineers, because we will take on the job of hosting a lot of our customers infrastructure, so we need to have really good infrastructure engineers. That's something that we're on the look for, as well as frontend engineers and general backend engineers with type, script and go experience. That's also something that we're looking for. Ben: Awesome. Well, thanks so much for joining us. This was really interesting to learn about Nhost. We will put a link in the episode description, both to Nhost and to your careers page. Johan Eliasson: Sounds good, sounds good. Thanks for having me here, Ben. Thanks. Brian: Hi. Thanks for listening. Please remember to like, subscribe. Email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah. We'll see you next time. Thanks.