00:00:00 Kent: What's up, everybody? This is your friend can't see dots and I'm joined by my friend a honey a kitchi-ku How are you doing, honey?

00:00:08 Iheanyi: All right doing all right. Yeah, it's good to be here.

00:00:11 Kent: Did I get your name, right?

00:00:13 Iheanyi: No, but it's okay. I know it's e. Hi. You got the first name pretty good. Last name's Ekechukwu. But you know, Ekechukwu, it's hard, man. It's a lot of letters. It's intimidating. I get it. I know. But it's all good. So yeah.

00:00:24 Kent: No, no, but like you spend your entire life correcting people on the pronunciation of your last name. So I am genuinely sorry. That's okay, man. I will do

00:00:32 Iheanyi: better. It's all good. I appreciate that. But yeah, I'm happy to be here, man. Thanks for having me.

00:00:37 Kent: I'm super jazzed to have you here too. So, Ihani and I go back like quite a ways, honestly. So, I had you as a panelist on JavaScript Air, the live broadcast podcast back in 2015, but I feel like we knew each other before that as well, and I can't remember exactly where

00:00:56 Iheanyi: we first met. Twitter, probably. Like, you know, I was doing a lot of React stuff back in, well, back in the day, still doing a lot of React stuff. And I think I'll just like, you know, back whenever the whole framework wars were going on, with like Ember versus Angular versus React, you know, I was a huge Ember stan. I still am, I still use a good framework, but then I moved into React for like other jobs. And like,

00:01:16 you know, React has kind of grown on me over the years, especially with like new frameworks popping up. So yeah, just like, you know, classic Twitter friendship.

00:01:25 Kent: Yeah, yeah, those are good. Those are good. Well, cool. So it's been awesome for me to get to know you over the years. Why don't you give us a little intro to yourself, like who you are and what you stand for, all that.

00:01:36 Iheanyi: Yeah, all right, well, bet. So yeah, once again, name's Ehii, software engineer at PlanetScale. We're trying to build the best database for developers on top of MySQL and Vitesse. Basically, we wanna make it easy to make a database that's performant, scalable, and charitable, right?

00:01:57 I've been at PlantScale since November of 2020, and I work on the surfaces team, meaning everything that the customer touches is my team's responsibility. So whether that's the CLI, the admin dashboard that you see the AP and the API SDK's, even like

00:02:18 the serverless driver that we have, or the serverless JavaScript database driver that we have, like my team works on all those. And yeah.

00:02:29 Kent: Cool, cool. And before that you were at GitHub?

00:02:32 Iheanyi: Yep, worked on GitHub Actions for a nice 2 and a half years from like alpha to like where it's at, like to like GA and like helping scale it up and stuff like that. So it's been fun. I like developer tools a lot.

00:02:43 Kent: Yeah, yeah, obviously. Well, that's good because you've spent a lot of time doing it, so I'm glad you enjoy your work.

00:02:48 Iheanyi: Yeah, yeah, no, right?

00:02:51 Kent: Cool, yeah, so PlanetScale, I first heard of PlanetScale back in, yeah, around 2020 as well, when I was working on a rewrite of my website and I was deciding, okay, so where do I wanna host stuff? I was hosting on Netlify, but I wanted, I was using Remix or starting to use Remix at the

00:03:11 time. And I wanted to go, you know, planet scale. I wanna deploy to multiple regions all over the world. And I quickly found out that if you, like you can deploy to multiple regions all over the world. And I quickly found out that if you, like you can deploy to multiple regions all over the world, but if your data is not in that same region, like next to where you're deployed to, then it

00:03:31 doesn't do a ton of good. Like it is a little bit, gonna be a little bit better probably, but you gotta put your data and your authentication and alongside your deployed servers as well to make it better.

00:03:44 Iheanyi: Yeah, so speed of light is real, yeah.

00:03:47 Kent: Yeah, yeah, for real. And so, yeah, PlanetScale was 1 of the ones that I looked at because of you know that distributed nature of planet scale ultimately I went with fly because then I could do hosting my service, like my server alongside the Postgres cluster. And

00:04:07 that ended up working out. And then eventually I went over to SQLite and it's been kind of interesting history there. But yeah, so PlanetScale has been doing some pretty cool stuff. And like, talk about 1 of the best names in the business to like right when it's like perfect.

00:04:22 Iheanyi: So

00:04:23 Kent: yeah, yeah. So that's cool. What would you say is the most interesting unique differentiator of planet scale?

00:04:31 Iheanyi: I think it's a so hard. I think the main thing that I want to say is that, well, first things first, I think like the main differentiator is like, you know, the ability of scaling, right? Like I think in the last 3 plus years we've seen a like rise of mad different like

00:04:51 database startups, right? A lot of them are like, you know, you got like CockroachDB, which has been around longer than that, but now they like have like, you know, released like a serverless workflow. You have like, you know, Neon and Superbase and others. And then like this whole vector databases and all like that. I think the main thing is just like, you know, when it comes down to it, PlanetScale is kind of unique in the sense that like

00:05:11 we're built on top of a test, which was used at like YouTube back in the day to help scale up their traffic, like back in the early 2010s. And that's like battle-tested technology. I'm familiar with the test, cause we used it at, like GitHub is a heavy user of it as well, so I had used it there.

00:05:31 And I think that's nice, because it sits in front of MySQL, making it easier to scale. And also when it comes out to sharding, it just handles it for you. You don't have to change much. You don't have to change much application logic, if at all. It just works. And that's what I like about the core infrastructure level of it, but then we have other things built into the product like

00:05:51 non-blocking schema migrations. Some people, like me, back whenever I was younger or doing a side project, if I'm hosting something on Heroku or something, I would just apply to database migrations on top of like while deploying, right? But yeah, is that always, you know, in reality, that's not like a best practice at beer companies. Whenever we would do database

00:06:11 migrations, we'd have to stage them separately and then like wait for database administrators. So apply to migration and then we can roll out our code changes after that's done. But we built this as a first-class-like product in the, or feature, rather, in the plant scale with deploy request. You can queue up, you can branch off your production database branch, and then you can apply a new schema to

00:06:32 that copy of your database branch to update the schema, open a deploy request, and then it's similar to a GitHub pull request. You get an approval from a teammate, and then with 1 click of a button, you can deploy changes. And that will deploy the schema changes to the production branch with 0 downtime. Whereas in other databases, right?

00:06:53 Like Postgres, for example, if you try to do that, if it's a large database, you can deal with locking. And even in MySQL, you can deal with locking as well. But the underlying infrastructure and code that does this, does it in a way that like, lets it be copied data in real time to another table and then like swap it over without any downtime, you know? So you have like, yeah.

00:07:13 So all of that's like non-blocking migrations and they can be long running. Like I've seen some migrations on like our largest tables take like 3 hours, right? But you can just come back to it and it works and you can like no downtime, 0 downtime whatsoever. And this is great. So I think we're like, like what I love about PlantScale and why I chose to work here is that, you know, we see

00:07:33 all these areas of computing, like, getting better, right? Like, you know, a lot of, like, focus on edge computing. We're in this little AI, like, renaissance. But I think, like, you know, It's funny you see startups for things like email. You see startups for things like the terminal or whatever. But databases really haven't gone through any innovation

00:07:53 in a long time. And whenever people think databases, they don't think like developer-friendly UX. I don't know, man. I just like making developer tools and making things easy for people. So, it seemed like a good challenge to learn more about databases and just being challenged, you know?

00:08:10 Kent: Yeah, yeah. So, as a developer who was working in Ember and then React. Now you're over at PlanetScale. It sounds like you're doing a lot of user or developer as your user, but like user facing stuff. Do you ever get like pretty deep into the database side of things too?

00:08:31 Iheanyi: Sometimes, like I know how, I know, I just learned that from like previous gigs, you know. The main thing is that like, you know, I do front end, I do back end. There's an orchestration layer, which is a Go service. And then it talks to a Kubernetes operator. Sometimes I go into the orchestration service with like, I know how to write Go as well. But usually that team is like on top of like is pretty

00:08:51 on top of things. So I don't really have to. But yeah, yeah, we have database specialists. Like we have a lot of the test core maintainers that work at plant scale. So like I don't necessarily have to go deep into the weeds of things unless there's an interesting bug that's been reported to my team and we have to go and debug it ourselves and help open up an issue. But

00:09:11 usually it's like we have specialists in the company that know that are just like MySQL geniuses.

00:09:18 Kent: Yep, yep. We'd always appreciate those people for sure. Yeah, for real. So you've been there, when was the company started? Were you 1 of the first employees there?

00:09:30 Iheanyi: Funny enough, no, but it feels like it. The company was actually started in 2018. I was brought on by the CEO, the now CEO, to help rebuild what is like PlanetScale of today. Yeah, so basically

00:09:47 Kent: it

00:09:47 Iheanyi: was like a pivot, still using like the same primitives and all that to make things amazing, right? But we built like a whole new product on top of it. And yeah, it's been great.

00:09:59 Kent: Yeah, cool. So as part of that building of a new product, I was told that you worked on the authentication for that. And authentication is a big part of what I teach in the Epic web workshops. That's actually, so

00:10:19 there are 5 workshop repos and most workshop repos are like 10 to 15 exercises, something like that. The auth 1 is like 23 exercises or something like that. So it's like just so much stuff involved with that. Yeah. I'd like to hear a little bit about the auth that you

00:10:39 built yourself and why you built it yourself instead of going with the service or when services made sense for you.

00:10:47 Iheanyi: Yeah, so honestly and truly, authentication is kind of a solved problem, and not kind of, it is a solved problem in Ruby on Rails. That's what the client scale API is built on top of, that's what we use for our internal admin panel, and that's what we use for our authentication. There's a gem in Ruby, there's a Ruby gem called

00:11:07 Devise, and that's kind of like the standard for authentication, which is great. You just like install the gem, it also generates like the templates for you that you need for a login form. Toss that off to a designer and they work with it and they apply their little magic to it and it's pretty much done. And it handles session, like it handles

00:11:28 the session management and all that good stuff as well. Password, like password confirmation, password reset, forgot password, yeah, like forgot password flow. Like everything is built in out of the box with that, right? And every single company, not

00:11:48 every single company, but a lot of companies use Devise. It's been used for years. There's alternatives like RodAuth if you don't want to go the Devise route. But I just like Devise because 1, it's what we already knew. Like GitHub runs on Ruby on Rails, right? So we have a lot of Rails specialists at the company. And it also plays nicely with other gems like

00:12:08 OmniAuth, which is what we use for our GitHub authentication via OAuth. And the plugin for device authorization grants that we use for the CLI to have that nice little login flow when you do PScale login.

00:12:24 Kent: Yeah, yeah. So it sounds like, or honestly, it sounds nice for a developer working primarily in the JavaScript ecosystem where we can't really agree on anything.

00:12:37 Iheanyi: That's the problem.

00:12:39 Kent: Yeah, having a 1 package that kind of does it all. I think that's part of what I'm hoping to be able to do with the Epic stack. I don't know if you've seen me tweeting about the Epic stack, but it's just like this stack of tools or a starter project and a reference for people. And there's

00:12:59 a lot of code in there for managing the authentication stuff. And eventually I'm hoping to turn the auth stuff into a package that's like, where implementing auth in a product like PlanetScale can be just as much a non-story as it was for you when using Rails.

00:13:19 But you mentioned also that you do support single sign-on and SAML and stuff, so do you want to talk a little bit about that? I don't think that I've ever heard anybody say simple and SSO in the same sentence. So,

00:13:35 Iheanyi: and that is comes to like, you know, when I believe in like, you know, build versus buy a lot of people want to like, I think the whole discussion that was on Twitter, like whenever this whole off topic was going on, I think people were talking about third party auth services to handle everything, like, you know, the user, like, you know, the user logins and all that other stuff, and like the user management,

00:13:55 this, that, and the third. And to me, I think that third party auth services have a time and a place, but not necessarily for the core authentication experience. Like at least at least when like, you know, languages like Ruby, Python and even like, you know, frameworks like Laravel

00:14:15 and PHP, like all of their, all these languages have like figured out the authentication aspect of it, right? And like, you want to store your users in a database, right? You want to be able to query what your users are doing and attaching it to them. And Once you outsource this to a third party service, you're beholden to their like uptime, their reliability. And so

00:14:36 many things can go wrong, right? So I like the hybrid approach that we have at PlanScale. We actually do SAML and SSO for our enterprise customers that is powered by WorkOS. And what I like about WorkOS is that, it's funny, they do have like traditional path authentication methods, like I think, like username, password, or like

00:14:58 magic links over email. But we just use them for the SAML and SSO parts because SAML is not simple, but what I like about it is that we can still use device, but the way that WorkOS is architected, that we can just sprinkle that in on top of our authentication system, and it's not fully locked in vendor-wise to it, right? And it really thought through the flow of like making SAML

00:15:18 and SSO easy. And even we took it to the next level by using the directory sync product. So like basically whenever something changes in LDAP directory, the reflection of that is like reflected in like the PlanetScale organization. You can map like directory groups to teams in PlanetScale. And this do a lot of us, like a lot for us that would

00:15:38 be really difficult to do on our own. And like having that technology And given the fact that it's providing value to some of our highest paying customers, makes it a no brainer, right? Like it's just a really well thought out product and like doesn't get in the way. It's just like you can use it no matter what else you're using,

00:15:58 right?

00:16:00 Kent: Yeah, yeah. I agree with that. I think that like, even if people do decide they want to use a auth service for the basic stuff, which I don't think that most people should, but even if you do, you should definitely keep your user data in your own user table. Like I can't

00:16:20 imagine relying on a third party to get user data on every single request.

00:16:26 Iheanyi: Yep.

00:16:26 Kent: Like that just sounds like a really, really bad idea. And then like on top of that, there's the vendor lock-in and all that too, of course. But yeah, using a third party to manage the really complicated stuff like SSO and SAML, I think makes sense. There are some really

00:16:46 sweet libraries coming out for doing SAML. And there's a lot of enterprises are moving to OpenID Connect as well, which is a lot easier. So yeah, the future, I think, this is still a bit of a moving target when it comes to third party auth and stuff like that.

00:17:08 But yeah, it's an interesting world there. Yeah, I'd like to

00:17:12 Iheanyi: say though, WorkOS has support for multiple languages, right? Like we use a Ruby gem, and it works like a, no pun intended, gem, or works like a charm. But yeah, they have Python support, JavaScript support, PHP support, all that. But yeah, it's pretty good. But I'm always interested in seeing what happens with

00:17:33 the ecosystem. Because Sam 1 SSO is just like all the certificates and stuff that you have to manage and like, it's just so grimy.

00:17:38 Kent: Yeah, it sounds awful.

00:17:40 Iheanyi: Yeah, no kidding.

00:17:42 Kent: Well, and also LDAP support. I didn't even think about that, but like, that's pretty, yeah, that's a couple engineers. That, you know, maybe 1 full-time engineer just dedicated to that, that you're saving by just paying WorkOS.

00:17:58 Iheanyi: I am the only 1 that like, a coworker of mine set up the initial like, connection for like SSO for WorkOS, and then I'm just like on the hook for all of the LDAP stuff, like the directory syncing, logic, how it interfaces and interacts in our product, and stuff like that. We actually dog food it and use it internally as well for mapping to teams,

00:18:19 for admin rights and stuff like that, and combined with other things like access request and Okta or whatever, this is a nice automated workflow and allows for really powerful things within a project.

00:18:31 Kent: Yeah, yeah. Well, and without it, you wouldn't, like you said, you wouldn't have those big paying customers. Like that's where so much of the money comes from for a B2B SaaS company like Plants.

00:18:42 Iheanyi: Correct, yeah, exactly.

00:18:44 Kent: So may as well get it right. It's worth what it costs for that. But I will not back down on the don't use it for your basic auth stuff and like when you're just trying to get off the ground it just seems silly to me to pay a service for something like this. It can just be installed.

00:19:01 Iheanyi: I agree. Yeah, I agree. It seems like the only time I feel like it makes sense in this case is like some languages, right? Like I'm gonna use Go as an example, even though I like love the language. It's hard building a web product and like using Go, right? Like you have to do ORMs really on our thing in the ecosystem or it's

00:19:21 kind of like discouraged. And I've written a lot of Go, like we use it at GitHub for like the actions, like the main action service I worked on. We use that plant scale for our orchestration layer. But it's like, you know, authentication with Go, like you have to do all the salting and like hashing of the password yourself, this, that, and the third. So I can understand why people would want like

00:19:41 offload that or outsource that to like Auth0 or something else because like the story for Go is not really good for authentication, like in terms of like the packages and ecosystem. But other languages like, you know, Ruby on Rail or other frameworks like Ruby on Rails, Django, Laravel, doesn't really necessarily make sense to me. I think like in JavaScript,

00:20:02 the struggle comes within the same thing. Go is such a primitive language, and I think JavaScript or Node.js is kind of similar in that they didn't have... There's no agreed-upon Ruby on Rails equivalent for JavaScript.

00:20:22 There's no Django equivalent for JavaScript or Laravel. Some frameworks might claim that they are, like a full stack web framework, you know? But at the same time, it's like, I think of it like, whether it's like, you know, Remix or like Next or Nuxt or whatever, like, you know, whenever I think about full stack web frameworks, I think about

00:20:42 like, you know, Django, Ruby on Rails, Laravel, handling database migrations for you. It comes built in with mailers, a templating system. Some of them even come with their own job runners, like ActiveJob and stuff like that. Whereas I think of more of these full stack frameworks, similar to micro frameworks like

00:21:02 Flask and Python or like Sinatra and Ruby, you know, because they really just handle like the templating and the routing, right? And like the service side rendering. And that's pretty much like the, and then you have to bring in and build your own framework. And that's what you have to do with Flask and Sinatra as well. You don't have that whole ecosystem that makes it completely full stack. But I think they just use full stack into front

00:21:23 end and back end sense. Like, oh, I can make an API route. I can also server-side render some HTML.

00:21:29 Kent: Full stack, yeah. Yeah, I actually really appreciate that perspective because I think for a lot of us who spend all of our, myself included, we spend all of our time in the JavaScript ecosystem only, we kind of forget that outside of the JavaScript ecosystem are frameworks that do way, way

00:21:49 more for you that we just don't really have in the JavaScript ecosystem. I'm hoping to change that with the Epic stack. Like I really do want to build like the Laravel for JavaScript.

00:22:00 Iheanyi: I hope you're successful, man. But it's always funny because even if you do do that, somebody's always going to have a different opinion and try to build something else to make it better. Is this like a never-ending cycle?

00:22:13 Kent: That's just the way the JavaScript ecosystem is.

00:22:15 Iheanyi: It's so interesting to me watching it.

00:22:19 Kent: Yep, yep, 100%. Yeah, so, you know, 1 other point that I want to make, and then I'd love to move off from auth to like other stuff, but other point that I wanted to make was, even if you do have an auth gem that you can install or just like came with the framework, I think that it's, you'll be a lot more

00:22:39 effective using those tools if you understand the like lower level primitives on what they're like, how they're built. So like understanding how cookies work and sessions work and everything will just make you a way, way more effective user of those technologies.

00:22:55 Iheanyi: For sure.

00:22:58 Kent: Cool, yeah, so let's talk about other things that you've been working on PlanetScale because you mentioned to me that like, I don't know man, Auth is like 1 of the smallest things that I've done here at PlanetScale. So what are some of the other more interesting things or things that you're more interested in that you worked on at PlanetScale?

00:23:16 Iheanyi: Man, honestly, everything. I don't know, like I helped build like the most of the CLI. I helped build most of the Go SDK. Yeah, the CLI is written in Go. We did that because it can be compiled. Like the binaries can be compiled across like a different operating systems like mad easily and we just automate that in CI so it's kind of dope.

00:23:39 I helped work on deployer quest and the whole infrastructure diagram that you see whenever you go to a database overview page like I was part of the team that helped build that. The database branching feature. I also did that when I was like 1 of my early projects at client scale when I first joined.

00:23:57 Kent: Mostly backend work for this stuff. Are you doing both the front end and backend for this?

00:24:01 Iheanyi: Both the front end and back end. I really shout out to our designer, Jason Long, because what I love about him as a designer is that not only is he a really good product designer, but usually he's like, danger enough in code to actually handle the routing and like making the static mockups in like, even like in React, cause he's next JS on the front end, Ruby on Rails

00:24:21 in the back end. And then we just like, once he gets hits like a wall, he's like, okay, well, I want somebody, the UI is ready, I just need somebody to handle the like, you know, state management portions of it. And he has comments on what the state should be

00:24:34 Kent: and

00:24:34 Iheanyi: how to interact, and it just makes my life so much easier. But usually I do, yeah. But usually if his hands are full, I can also do the front end stuff like spec. But usually he's pretty good about testing out his designs in the front end to make sure it feels right.

00:24:48 Kent: Yeah, yeah, very cool. Yeah. Cool, well, yeah, let's see. Is there anything else that you wanted to chat about that you think people wanting to build epic web apps would want to know about?

00:25:01 Iheanyi: Yeah, I mean, like, if it's an Epic web app, you're probably going to be deploying it to, like, you know, your Vercel, your Netlify, or maybe your Cloudflare for it, right, in the edge. And I just want to say, like, you know, PlantScale, like, has an edge compatible, like, or has an edge friendly serverless driver

00:25:21 for JavaScript. And it plugs in with like other frameworks like Drizzle and Keysley. And I believe Netlify is working on supporting it as well. So highly recommend it. It like handles all like the connection caching and like reducing latency. It's really good in edge environment. So I had to like plug that. But other than that, like, you know, I also work on

00:25:41 that database driver as well. So me and my coworker David. Yeah, so.

00:25:47 Kent: Yeah, so the, with the Epic stack, we deploy to fly.io. And so you can deploy it to multiple regions, but it can be a long running server. So like fly is kind of like a long running server, serverless platform. Yeah. And deploy to the edge and all of that too. It's not quite the, what is it like 300

00:26:07 regions that CloudFlare has.

00:26:09 Iheanyi: Yeah. It'll get there eventually.

00:26:11 Kent: Yeah. Yeah. Well, and it's, it's good enough for what most people need as well. So, but yeah, being able to manage, like for a lot of people using serverless architecture, with short-lived functions and stuff like that, Being able to

00:26:31 connection pool all of that stuff and not have to worry about it, that's pretty cool.

00:26:36 Iheanyi: Yeah, for sure, definitely, definitely.

00:26:40 Kent: Well, cool, honey, thank you so much for chatting. This has been awesome.

00:26:43 Iheanyi: Thank you for having me.

00:26:45 Kent: Yeah, to visit with you again. What's the best place for people to keep up with you and what you're doing?

00:26:50 Iheanyi: Yeah, so for keeping up with me, you can hit me up on Twitter or X, whatever we're calling it these days. My handle is at KWUCHU. And yeah, if you have any questions, DMs are open, holler at me there, or hit me with an at, and yeah. And also, if you wanna check out PlanetScale,

00:27:11 our Twitter handle is at PlanetScale.

00:27:14 Kent: All right, yeah, That's easy. And again, man, that name is the best. It's brilliant.

00:27:21 Iheanyi: So yeah. Follow for a chance to win a database hat.

00:27:24 Kent: Yeah, yeah. Dude, that hat is also very cool.

00:27:27 Iheanyi: Thank you. Thank you.

00:27:28 Kent: All right. Hey, thanks a lot, man. You all take care. We'll chat

00:27:31 Iheanyi: with you all later. Later, y'all.