Kate: Welcome to PodRocket. I'm Kate, the producer of PodRocket. And with me today, is Jon Meyers, developer advocate at Supabase. Hi Jon, how's it going? Jon Meyers: I'm great. How are you? Kate: I'm doing well. Yeah. This is, at the time we're recording, almost exactly a year since we had Paul Copplestone on the podcast. Very exciting to have you back on, and we'll do a check in on 2021. Jon Meyers: Yeah. I think being a small startup that moves very, very quickly, I'd say there's probably a lot that's changed since that point. Kate: Yeah. Yeah, totally. And also with me, is Paul. Hi, Paul. Paul: Hi, Kate. Kate: Thanks for joining us today. Yeah. Jon, maybe if you could just get started on what you're working on and we can just go from there. Jon Meyers: Yeah, cool. As you said, I'm a developer advocate at Supabase. I've been with Supabase for about six months now and have been just trying to build up developer advocacy from scratch. Myself and Thor, who was previously at Stripe, have just been trying to do as much as we can in every way and trying to create lots of content and documentation and trying to just show off all the cool things that the geniuses at Supabase are working on. Paul: Is that what a developer advocate does? Do you make the platform really approachable and ... Jon Meyers: Yeah. That's one of the parts. There are three pillars I guess, to developer advocacy. There is the content creation stuff, which is probably where I spend the majority of my time at the moment. And so that's where you're writing blogs, creating video tutorials, maybe doing conference talks, things like that, going on podcasts like this wonderful podcast. That's the content creation side. And then there's the community aspect, so trying to build up a community, trying to find those people that are building cool stuff with the product and trying to highlight them as much as possible, trying to give them a platform to talk about their things that they've built. And then the third pillar is the part that I guess, where the title advocacy comes from, is taking all of the feedback, because you spent so much time talking to people who are building with the product, taking all that feedback and feeding it back into the company to try and make the best product decisions, I guess. Paul: That's a very good explanation. Developer advocate seems like a really broad role. I was on the podcast with Nader, who had a similar role and it seemed a little bit different than what you're doing. It's cool to hear the other perspective of the more content and user focused side of that. Yeah. I've used Firebase before, I'm sure a lot of people have used Firebase. And it's pretty awesome because I just whipped up a website in a night and it did everything. Supabase is supposed to be that for people like me right, who want to use Firebase. Jon Meyers: Yeah. Yeah, exactly. Supabase was first positioned as the ... I think it's still the marketing material everywhere but it's the open source alternative to Firebase. And so the founders of Supabase basically had that exact experience. They built with Firebase and it's just awesome. The developer experience is fantastic. Something that some people hit, which the founders of Supabase hit, was a scaling issue, where they couldn't do concurrent rights I believe, as quickly as they needed to. And so looking at using a relational database that's optimized for that scheduling of all those concurrent things that need to happen. And so yeah, that's where Supabase was born from, was basically wanting to take the awesome developer experience of something like Firebase but replicate it in a relational database world that's a little bit more scalable. Paul: The reason why there was this push right, to go to the relational database world, is because inherently in the... What is it? NoSQL database rights are expensive, right. Is there anything beyond the expensive rights reason that motivated Supabase to go in that direction or was it more the use case of, "Oh, we want good rights?" Paul: Or was it more like, "I'm going to stick it to the man and make an open source back end as a service." Jon Meyers: Well, I think open source has always been so important to everyone at Supabase, especially the two founders. Everything that we do is open source obviously. That's why we're the open source alternative to Firebase but yeah, it's always been such a massive focus. And so I think that were just excited to build something open source that solved that same problem. But yeah, I think that as applications tend to scale, you have those problems with reads and rights but you also ... Not having relationships in a database when you just have a collection of separate documents, a lot of the time you need to do multiple round trips to the database to request the different bits that you need. You might get back a list of all of your blogs for example, but you need all of the content for all of those blogs or all the titles for all of those blogs. And so then you need to go off and make a separate request to get more data about each one of those. Jon Meyers: Yeah, a relational database just solves that problem by having relationships between your data. You can send one big query that gets you back everything that you need all in one go. Not just the technical limitations of how quickly you can read and write, but also just how efficiently you can request the big blobs of related data that you need from the database. Paul: Thinking about the way those queries are orchestrated, when you're taking something like Postgres and you're making it as such a easy to use service, what was one of the hardest scaling considerations, being one of the first people that wanted to take this to this level? Jon Meyers: Yeah. Paul: Because anybody that knows that, when you're trying to chard out Postgres in a smart way, it's not daisies and rainbows. I'd love to hear a little bit about that. Jon Meyers: Yeah, for sure. I think that's definitely beyond my experience with Supabase. I definitely haven't been working on the performance side so much but I think from the developer experience side, which is probably where I could talk more to, I think that SQL tends to scare a lot of beginners. And so writing big SQL queries just to get the data that you need out of the database or to write something to the database, I think intimidates a lot of beginners, especially coming from the Jamstack ecosystem or potentially the mobile development side of things. And so I'd say one of the big problems that we were trying to tackle with Supabase was really nailing that developer experience and really building something that people with very little experience building backend systems could use, because that's what we're trying to abstract. We're obviously a database as a service or backend as a service service. Jon Meyers: And so being able abstract away the complexity of that and give people really nice tools that they can use to interface with that database was definitely one of the big things we were trying to solve. But in that, you don't want to just give people a very slim set of tools that they can use to build their application. Because then when you get those more advanced use cases, the user can't really solve those problems. And so one of the big things that we've always tried to do with Supabase is to ... Because it's just a collection of open source convenience tools wrapping around a Postgres database, we want to make it as obvious as possible that it is a Postgres database and we want to give you tools to be able to interface with that database directly. Jon Meyers: And so in Supabase, you can go over to the SQL editor and you can basically write SQL that executes directly on the database. And so by trying to solve those onboarding easy DX problems that exist with learning SQL, but then also giving people the superpowers that they need once they start building a more complex application, I think they're the two things we're always trying to balance and make sure that we solve both of those use cases. Paul: I've never used Supabase myself, I've only used Firebase once or twice. If I was trying to use Supabase tonight to make something, what do you think is the number one spot that you see a lot of people coming on for the first time having trouble? You mentioned SQL but if you're ... Let's say you're a developer right, you know some SQL. What's one of the other places that you might want to watch out or put your thinking cap on, or a good place to go get resources for that? Jon Meyers: One of the really cool things about Supabase is that it uses Postgrest under the hood. And so that's Postgrest, Postgrest with a T. And so this is a tool that allows you to interface with your database with a rest client. But the other thing that it adds, is auto documenting or auto generating documentation. And so if you go to the API tab, I believe, in Supabase, it basically shows you automatically generated documentation based on your actual project. Every time you create a table, it will auto-generate the documentation for how you can insert rows into that table, how you can select rows from that table. And so that's a really, really great place to get started when you first start using Supabase. It'll teach you how to create a client, how to write data, read data, all of those things. But I think, probably the number one sticking point that people have when they first come to Supabase, is dealing with Row-Level Security. And so we use Row-Level Security for authorization. Jon Meyers: And so this is a way that you can write your authorization rules in the database itself, and the database will enforce them for you instead of needing to ... For example, instead of needing to check that ... Paul: It's like Firebase a little Bit, right. Jon Meyers: Yeah. Yeah, exactly. Very much inspired by that but Row-Level Security itself exists in Postgres. And so this is again, one of those features that's already in Postgres that we can take advantage of. But I think just that way of writing access policies in SQL is something that trips people up a little bit at the start. I think they're very used to connecting to their database from their API instead of their client. And then at the API layer, they are writing JavaScript or whatever to enforce that the user has the right role to see what they're trying to access. Whereas in Supabase, because we know who the user is, because we do authentication and your database storage, we know who the user is that's trying to select those records, so you can make a request directly from the client to the database and the database will enforce that they can only see what they're meant to see. And I think that's a very confusing sticking point for a lot of people because they're just not used to that mental model coming from potentially the Jamstack ecosystem. Paul: I feel like that whole method of authentication is also ... It's definitely a product of the modern times, where we have all the SAML and single sign on and we're just changing the off model to having that one person that can authenticate with the database. One thing that I had to gripe with when I was using Firebase and I was ... If you can clear up any suggestions for workflow or ways to think about this, or maybe it's just you need to spend time with it. But I felt like it gave me more control over the data but it slowed me down when I was developing it because I was always going back in the data database and saying, "Oh, I got to change ... Who's this user? What permissions do they have?" Paul: Well, once you got it right, it was pretty nice because you could just write off of it. Jon Meyers: Yeah. Yeah, for sure. Paul: Yeah. Jon Meyers: I think that's maybe something that is inherent to this, is that there is a little bit of work to do upfront because you're writing your policies. You're not just creating a table and then you have immediate access to it. Or you can do that in Supabase. You can also turn off or by default, Row-Level Security isn't actually enabled. You do have just read and write access to the database. But yeah, I guess that's something that's inherent to writing access rules in your database, is that something that you think of upfront? And so there's a little bit of work that you need to do to make sure that you're locking down your database in the correct way or enabling access in the correct way. But I guess, that scales nicely because you get all of that set up initially right, when you're building the application, and then there's less friction as you're going because all you need to do is every time you need to enable access for a different use case or whatever, you just need to write one policy and everything else is already set up. Jon Meyers: It also protects you from writing some bad logic down the line that does expose that data, because those rules are written in the database themselves. And so at the API, you can't really expose things that you're not meant to expose because everything is being enforced by the database itself. Paul: I have one last question about the actual technology of your stack. I'm thinking about this Postgrest thing, right. It's this other layer that's sitting in between me and my database and other things that I think about that do that, are PgBouncer or some other ... Postgrest, what role does it play? Why is it there? And how do you see it benefiting developers besides just the abstraction layer? The abstraction layer is pretty ... Any abstraction is good if you don't want to get your face in the weeds, right. But I'd love to hear a little bit more about what the role of Postgrest is. Jon Meyers: Yeah. Postgres gives us that magic of making everything feel really, really tightly integrated. That's one of the things that is really special about using something like Supabase, as I was saying before, you've got auth and you've got the database stuff and you've got Row-Level policies. They're all living inside that that ecosystem of Supabase. And so in your Row-Level policies, you can see who the user that's making that request is, because you're handling that whole end-to-end experience. And so that's something that Postgres gives us access to, is because the user is making ... The client is making a request to Postgrest and then Postgrest is going off to the Postgres database, basically it gives us access to the JWT token that got passed along with that request. Usually in the database, you can't inspect ... Without writing a lot of custom code yourself, you can't inspect what the JWT was of the client who made that request. And so Postgrest nicely passes along all of that information. Jon Meyers: In your Supabase RLS policies, you can see who the user is that's logged in but it also means that you can detect who the user is throughout any of those things that you're doing with Supabase. If you're writing Postgres functions for example, then yeah, in your Postgres functions, you can see who the user is that's made that request. It also allows us to do things make a request to a Postgres function from the client. We can create a Postgres function that has a whole bunch of complicated logic in it, a whole bunch of complicated, scary SQL. And then we can just expose that as a Postgres function that we can call from the client. And so again, because the client is passing across that authorization token, they're passing across that JWT token, we can make sure that they're actually allowed to run the SQL that exists in that Postgres function. Postgrest with a T, ties all of those things in together. It's the layer that basically gives Postgres the knowledge of who the requesting user is, and also just provides a really nice interface for the client to request that data. Paul: Yeah. I was going to say, it sounds like a nice interface. It's just a really good bed to build SDKs off of really quickly that you can pump out once you get that layer sorted out. Jon Meyers: Yeah. Paul: Yeah. Jon Meyers: Yeah. From the client side, it gives you that convenience and that nice simple API. And from the database layer, it gives us access to who's actually asking for that information. Paul: What are some of the coolest projects that you've seen? I can look up Supabase and see all sorts of big names on there, but what do you think is cool, some compelling use cases or some people that maybe stretch the product, that informs some future building decisions? Jon Meyers: Yeah, for sure. There's this awesome site called Made With Supabase. I think it's just madewithsupabase.com. We'll chuck it in the description. And it's a community built project that just basically lists out every project that we have ever heard about that is using Supabase. And so it's a really cool place to just click through and see the awesome stuff that people are building. A unfortunately recently sunsetted project that I was really excited about, was Slip. Slip.so Was an educational platform that was built on Supabase and it ... Yeah, had some really nice interactive educational courses but then also from the content creator side, it allowed the person who was building the course to charge for the course up front. They could basically get people excited about the course and committed to buying it by purchasing the course before it had actually been created. Then it gave you the inspiration to create the course. Jon Meyers: Another awesome one that I saw recently was a links ... It's just a massive Figma file of just all of the links that you want to of keep a track of. If you think about a visual version of your bookmarks toolbar, so everything that you want to be able to bookmark and come back to later, you drop the URL into this Figma file or this thing that looks like a Figma file, and it will go off and get a preview version of the website and have it there and bring in a bunch of the OG image information and stuff. Just a really nice collage of all of these things that you want to keep a track of. But yeah, there have been so many cool, awesome projects built with Supabase. I recommend checking out the madewithsupabase.com website. And yeah, checking out what can be done. Paul: Yeah. I just pulled it up and there's a lot, there's a lot of stuff here. That's cool. There's a lot of good inspiration to look at what you can do with this. Jon Meyers: Yeah. Paul: What do you think is the biggest strength of Supabase, besides what we've talked about in the beginning, like the row based access of your relational data? Jon Meyers: Yeah, I think having the power of Postgres behind it, so having almost infinite scalability and such a battle tested database technology that's just been around forever. But the real strength I think, is because we're wrapping these tools around just a Postgres database and giving you direct access to that Postgres database, it makes Supabase very portable. And so most systems might give you the ability to export out your data as a CSV or something like that. But in Postgres, you can take a whole dump of your entire database, and because with Supabase we're doing things like writing Row-Level policies or Row-Level Security policies in the database itself, all of that comes out as well. And so it's not just that you get a CSV that you then need to work out how to import into another database, you can take an entire dump of everything in your Postgres database or everything in your Supabase backend that you've built, and go and host that anywhere else. Jon Meyers: Yeah, it's super, super portable, which is awesome from a ... Just not being tied into or having that vendor lock in with a particular thing. But it also means if we fail ... We're building things very, very quickly and scaling up way faster than we can probably afford to most of the time. And so if something did happen where we ended up not being able to handle that and collapsing as a company, it means that all of your stuff is still safe. You just dump it out and go and put it somewhere else. And you've still got your application still running. Paul: The fact that I can run it myself is wild because one thing about Firebase that attracted me at the first part was, "This is easy. I don't need to think about it. And the SDKs are there." Paul: And Supabase has all of that but if you're a DBA or you're a systems guy or whatever it might be, you can take that and you can stretch it and optimize it to really penny pinch and get the cheapest backend that you can get. I feel like that is one of the biggest things in my mind. I'm just like, "Wow." Paul: And there's a lot of open source tools out there for tuning. How tuneable is the Postgres backend of things. Can we play with that? How do we do that? Jon Meyers: Yeah, yeah. We give you direct access to the Postgres database. Paul: And it won't mess with any of the way that Supabase on the application layer ... If you're poking, prodding Postgres underneath. I'm sure there's something you can do there. Jon Meyers: Well, it depends what you do I'm sure, because we give you access. Obviously, you do have the ability to shoot yourself in the foot but yeah, most of the things ... Yeah, if you were just in inserting some records or changing the structure of your database, things like that, obviously that's not going to affect Supabase. If you took the user or the role that Supabase is logged in as, and changed the permissions of that so that it wasn't allowed to see the database, then you might break your entire system. Paul: That doesn't sound good, no. Jon Meyers: Don't do that, don't do that. That's not recommended. But yeah, because you have direct access ... Paul: Don't try that at home. Jon Meyers: Yeah. Because you have direct access, you're not limited by the features that we're pushing out either. If there's something that you really want to be a part of your application that isn't supported by Supabase yet, you have direct access to the Postgres database. You can go and implement that yourself or even better, because the whole project is open source, you could build it into Supabase and get those contribution stickers, send you lots of t-shirts and stickers and thank yous. Paul: What if I wanted to set up master-slave replication? I could just do that and it would probably be fine. Jon Meyers: Yeah, you would be able to potentially set that up. It would be something to play with, not something I have experience with but yeah, be a fun one to try. Paul: Is there any other plugins that aren't part of the Supabase immediate repo that you have found others in the community finding useful and what do those do? Any logging type of things or dashboards out there. Or I know Supabase has their own but ... Jon Meyers: Yeah, we recently acquired Logflare, which is very exciting, that ... Yeah, we have logging in in Supabase now, which is awesome. But yeah, in terms of our other extensions, that are great, the HTTP extension is a really good one that allows you ... That's a Postgres extension that allows you to make a HTDP request from within Postgres itself. And so something that's really powerful about having a Postgres database is that you can create Postgres functions. This is something that I was talking about before. And having the HTTP extension means essentially, you can create a Postgres function that can make a request to a live API. And so one of the really common use cases for that is, you want to maybe create a customer in Stripe every time a customer signs into your Supabase application. And so you can create a Postgres function that goes off and creates a Stripe customer. Jon Meyers: And because again, we're in Postgres, you can then use a trigger which is another database thing where you can subscribe to particular events in the database and then call Postgres functions. And so in that use case, you could listen to changes on your user's table. And anytime a new user is inserted into that table, you could call this Postgres function, which goes and gets a Stripe user ... Sorry, creates a Stripe customer. And then because that Postgres function has direct access to your database, you can just update that row to have your new Stripe ID. You can have this automated system that's all taking place just when the user signs in for the first time. It can automate all of these things that are happening in the background. Jon Meyers: Another really cool extension that we've actually just built ... It's an open source extension completely separate from Supabase but something that we're soon to implement into your Supabase instance, is PG GraphQL. And so we've recently built an extension that allows you to ... Yeah, make GraphQL requests directly to your Postgres database, which is very exciting. I recommend you go and check out that project because I think ... Yeah, that's going to be probably a big addition to Supabase soon. Paul: Yeah, that makes me want to go use it right now. GraphQL is beautiful and if it's built right in there, that's phenomenal. And I know there's a lot of tried and true support that has gone on, merging those two technologies over the past few years. Yeah, time has come, right. That's really cool. Jon Meyers: Yeah. Yeah, it's been one that's been on the list for a while. And yeah, everyone's very excited to get that one into hosted Supabase instances. It's going to be very cool. Paul: And thinking back to the functions that you just mentioned, my initial thought when I hear what you told me, is these are Postgres run time Lambda functions almost because they're in their own little state of the world and they do their own things. Yeah, you're not in your head a little bit. Jon Meyers: Yeah, they're very similar to that conceptually. And so yeah, you have these functions that exist with than your database. One of the I guess, benefits of these over something like Lambda, is that because your database is an always on system, your database is always there running, waiting for requests. It doesn't spin up and shut down the same way that a serverless function does. It's always on. That means that you can do really interesting things, like set up a cron server, for example. There's a really good blog by Pal Copplestone, the CEO of Supabase, that basically shows you how you can create a cron server within Postgres itself, with just a very small number of commands. It's like a Lambda function but with database superpowers. Yeah, it's very cool. Jon Meyers: But while you're talking about functions, I should probably address that it's not the kinds of serverless functions like Lambdas that our community is constantly asking us to build. That's been something that's been on the roadmap since basically day one. It's always been something that we've wanted to get up and running properly but like everything within that Supabase ecosystem, it's all so tightly integrated in and you have access to everything in that Supabase ecosystem. And so we really want to spend the time to understand what people want to do with serverless functions and how we can build the absolute best possible, most integrated version of that. It's something that we're working on but we haven't quite launched it yet. But hopefully more on that soon. Paul: It sounds like you're really trying to ... The team's really trying to focus on what is in our ecosystem in the Supabase world, what is going to be that phenotype of Lambda? Because it's going to be a little different than what's up in the AWS guys, right. And you want to take that new phenotype and make sure it's as clean as it can be and it say, running. It's testing the waters right now, right? Jon Meyers: Yeah. Yeah, that's right. We want it to feel like you're still using Supabase. We don't want it to feel like you're just writing a Lambda function and you happen to be writing it in the Supabase UI. We want it to be entirely integrated into everything else, so you have the kinds of superpowers that you have with all of the other pieces of Supabase. Paul: That's exciting. I'm going to keep an eye out for this. And especially, I have really like the GraphQL integration. I'm going to keep harping on that. That's really cool. With all these technologies being a little different than AWS and GCP and those guys out there, do you think that's going to target the same exact audience when people are building? Or is the audience right now a little bit different, and do you see ... Do you see AWS and Firestore ... Not Firestore, Firebase. Yeah. Do you see Firebase and the other guys being a competitor Supabase or are you targeting a different niche of customers, hoping to take them over some day? Jon Meyers: We'll take all the customers. No. Paul: Yeah. Jon Meyers: Yeah, I think we see them as healthy competition. They're doing awesome things. If AWS went down, the whole world would go down, so we like having them there. But yeah, in terms of things like Firebase, I think that's ... The original positioning of the company was the open source alternative to Firebase. And so it was very conceptually tied to the capabilities of Firebase and what Firebase could do. And initially, we were looking at replicating each of those features that exist, so database or a place to store data, that being able to be subscribed to real time events on that data, being able to handle authentication and authorization and then file storage. They're all the core pieces of what make Firebase awesome but it's also quite limiting if we were to only build what exists in Firebase. Jon Meyers: And so I think that marketing headline is something that I think we want to maybe move away from in the future, as we want to build some things outside of the things that Firebase offer. There's so much more cool stuff that we could do if we're not limited by only building things that Firebase engineers have solved in the past. Paul: Can you tell us anything that people have been whispering about on the big round table about what those things might be? Jon Meyers: Some of them are just very, very early conceptual things but I think the idea of what we're ... The kinds of things that we're trying to do with functions for example, I think conceptually, people have this expectation of what it would be because of the things that already exist. And so we want to excel past that, we want to be able to build something that is even cooler than that thing could be. Because if you wanted to build a serverless function, you can already create a Lambda or you can ... If your client is hosted on something like Vercel, you've already got serverless functions right there. And so I think trying to build things that are beyond just what exists at the moment. But yeah, can't hint anything yet. Stay tuned. Kate: That's for the episode next year at this time, yeah. Jon Meyers: Yeah. Paul: Episode 200. Jon Meyers: That's right. Paul: The future looks bright. Yeah. I keep saying, I haven't really looked into Supabase personally that much but this just looks like the holy grail of the full stack engineer that likes to do things themselves. Jon Meyers: Yeah. Yeah, that's right. That's exactly what we're trying to tackle. The people that just ... The hobby developers that just want to play with something, all the way through to people that want to build very advanced, cool stuff. Paul: Right on. Well, thank you Jon, this was a great overview. I learned a lot about Supabase in this episode. I hope the viewers pick something up and ... Right. You can go to the Supabase documentation obviously, to go look at things. You mentioned madewithsupabase.com for inspirations. Jon Meyers: Yeah, that's another... Paul: And I assume a lot of those projects are going to be open source themselves, since this is an open source community. You can go look at them. Jon Meyers: Yeah. Yeah, yeah. Yeah, exactly. Another resource I would highly recommend you check out if you're getting started with Supabase, is a free egghead course that I recently launched, which basically takes you all the way from an empty project, all the way through to building a fully in production SaaS product that can earn you real money. And it's built with Next.js, Supabase and Stripe. I recommend you go and check that out. It gets pretty deep. Kate: Awesome. Yeah, we'll put all the links we talked about in the show notes and yeah. Jon, thanks so much for coming on. Jon Meyers: Thanks for having me, this has been awesome. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter. Or you could always email me, even though that's not a popular option. It's brian@logrocket.