The Epic Stack with Kent C. Dodds
===

Paul: [00:00:00] Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay ever tracking and product analytics tried for free@logrocket.com today. My name is Paul, and returning with us is Kent Cz. He's a speaker, teacher, trainer who is actively involved in the open source community.

Kent has been on Pod Rocket before. We've talked about fully typed web apps abroad. Topic indeed. But getting into type script and great ways to construct your projects. Some details on remix, and here we're sitting on video chat and Kent has a colorful rainbow remix symbol in the back, which is great. I know that thing is lighting up the room.

Kent, . At remix comp you gave a recent talk called the epic stack. So we're gonna be talking about the epic stack. The state of web development today, and it's really exciting to have you on the podcast so we can get into things.

Welcome.

Kent: Yeah, seriously, thank you for having me. I often say that the [00:01:00] best compliment you can give to a speaker, but I guess also to a podcast guest is to be invited. It back, so I guess it wasn't so bad the last couple times that you wanted to talk to me again, which I really appreciate. I hope the audience appreciates too.

Paul: Yeah, , we know the audience has appreciated just cuz of, questions that people write in and ideas that people have from listening to the talks that we've had. And today in particular, I feel like I'm excited to get into. The topics you're bringing up with this thing called the Epic stack.

There's stacks this, there's me, stack and lamp stack, and yours is a different flavor. It's not here's four technologies, let's

Kent: Yeah.

Paul: It's, we're talking about something a little bit different here, so , I'd love to give you the stage here. If we can just get into what inspired you to come up with the Epic stack, and I'm hinting at, it's a little bit different than like a basket of four technologies.

So what is it in its essence, the epic stack?

Kent: Yeah. Yeah, totally. First on that basket of four technologies thing what's interesting about that is as technology evolves you're unable [00:02:00] to evolve the tech stack as well, because you. You've pinned your name to the tech that you're using. That's why we have all of those different named stacks.

But that's why it's, the epic stack doesn't actually stand for anything. As far as the technologies that it uses, cuz there are just so many technologies you need for an app. So anyway, to summarize the idea I gave this talk at remix comp that described where the idea of Epic Stack came from.

So I'd refer anybody to go check out that talk later. But the basic idea is that. First of all, there are a lot of really awesome choices when building web applications these days. And regardless of which you choose, you're probably going to be okay. Because , there aren't really necessarily bad options.

There are some bad options for some use cases, but most of the time anything you like, you just throw a dart at a dart board and you'll probably be fine with that. Technology choice. And so given that the time [00:03:00] that you spend. Making decisions on these different technologies um, is probably not really well spent.

And what's interesting is we agonize over this decision a lot and it's just a really A challenging process to go through all of that when we're really just trying to build our apps. And the primary reason why we agonize over this, even though we all acknowledge that like all these technologies are great we could use any of them and probably be fine.

But we still agonize over it because the, The fear is that if we make the wrong choice, we're gonna have to dig ourselves out of that wrong choice in the future or it will just send our company under, right? And so the impact of a incorrect choice is really big, even if the likelihood is very low.

so it can be really nice if somebody just comes along and says, Hey, these are the tools and technologies that worked really well for me, they'll probably work fine for you. So, Skip the whole decision process and jump right into uh, something like this. And [00:04:00] another really nice benefit of doing that is you can really optimize a lot of things when you know all of the different tools and technologies that you're using.

I know I'm gonna be combining these tool tools together, so I'll wire those up and people don't have to worry about doing that themselves. The epic stack is basically a project generator and a reference implementation for people because people aren't like starting new projects all the time.

So it's also very much useful as a reference for people to just get going really quickly and, and not. Be so concerned about which technologies to choose because they're like, whatever you choose, it'd probably be fine. It's based on the apps that I have built and shipped from.

Small app internal applications at big and small companies to consumer facing applications that are shipped to millions of users all over the world every day. And so I've had a really broad range of experience and I am up to date on the latest technologies. And I have very well-formed [00:05:00] opinions about what technologies to use.

So if you want to build apps the way that I build apps, then you can get started with this and you'll be off to the races on a really solid foundation. That's the premise. We can talk more deeply about the specific tech choices, but that's the premise of the epic stack.

Paul: Yeah, we can get into the tech specifics a little bit, but one thing I think is that I wanna double click on is just the nature of the amount of technologies you've chosen and like where in the programming iceberg. They sit because I wanna bring us back to looking at the lamp stack or like the MER stack.

That's a 4, 5, 6 technology stack. And the whole point of that is decision paralysis. Don't decide we got it for you. That's exactly what you said here. But the epic stack is different. There's like a, some more sugar on it. Is that why you called it the epic stack? Is because you're like, this isn't just like the application, this is like everything like tailwinds in there, right?

That's a bold. Maybe we can pick that as our technology thing.

Kent: yeah, sure.

Paul: That's a bold choice [00:06:00] though, to some people.

Kent: Yeah, sure. if you go with the lamp stack now you still have to make a couple decisions and of course, like at any, whatever the stack is unless you're literally building the application that I use for the project generator like a notes app then you're probably still going to have to make some decisions.

But the , one unique aspect of the epic stack is the guiding principles. And there are four guiding principles that I have for the Epic stack that I think are really useful to put into context. 

Paul: Oh yeah, I'd love to hear them. Yeah.

Kent: Yeah. So the first one is to limit services. So I wanna limit third party services, but also services that we run and manage on our own.

So this is like my embracing of the monolith and Saying no to the serverless, microservices world that so many people have jumped on board with. Services just make things more complex that by default, as soon as you add a service, you have. Instantly made things more complex.

You [00:07:00] cannot avoid that. Nobody can argue against that. That is the way that it is. Sometimes that complexity is warranted and it actually saves you on other pieces of complexity. But as a default, I think it's wrong. And by going with a monolith things are way, way simpler. And if you disagree with that, then that's fine.

Don't use the epic stack. But this is like a really core part of what the Epic stack is about is limiting services. So even like there, there are some things that we cannot avoid. Like email. You're not building your own email. You will never get your emails delivered. It's a terrible thing, but it's the way that the world works.

And we do have email an email service that we're using, but as far as like third party services or even services that we manage ourselves, We wanna limit the number of those. And so that means as much as possible we're building things into the application that people would often stick into services.

Paul: an example of a common one.

Kent: Yeah. Yeah. So a common one is image hosting or file hosting. That's built into the app service.[00:08:00] And eventually we'll also do image optimization and stuff like that,

Paul: so no min Minayo, that's a separate service, you're saying? No. Like we're baking it into the 

next or 

Kent: gonna bake it in.

Authentication is another one that's baked in.

We're not using a service for that. So th there are certainly like some situations where it makes a lot of sense to use a service. But as much as possible we're going to limit services,

And so it's limit services, not avoid services altogether. So a another, and actually I said there were four.

They're actually let's see, six. So the next the next guiding principle is include only the most common use cases. So it is a project generator. And so I do expect that people will remove stuff, right? Some of it is here's a model for notes. But you're probably not building a note taking app.

And so you will be, Deleting some things. But like some of that we actually need to make it so that the tooling that's in there has a purpose. And so , there are going to be some things that you're gonna delete, but we do want to limit the number of things that [00:09:00] we're gonna be putting into the project generator.

And instead we'll put examples and documentation elsewhere. So that one's like more for from a maintenance of the project itself standpoint. Another is to minimize setup friction. And so I want to make it so that. You can get things going to production as quickly as possible. Just last week, I improved the C L I a bit so that it will actually deploy for you.

So we, one of the services that we are using is FLY io. I've been hosting with them forever. Yeah, they're. Phenomenal service.. That's basically like serverless, but for long running servers. So you don't have to manage uh, servers or anything. It's not a V P s.

So it's completely managed for you and you can deploy to multiple instances in multiple regions, all like over 34 regions or something like that. 

And it's a custom infra too. So when US East is down and the entire internet is on fire my website's still running just fine.

Paul: Yeah.

Kent: Not to say that they don't have their own outages and everything, tech is [00:10:00] hard, anyway, so the c l I will just ask you just a couple questions cuz again, we're trying to limit the number of decisions you have to make. The only decision you really have to make is what region do you want to start in?

And that will default to the region that's closest to you. Everything else, it's just like, do you want to set up deploy right now? Because maybe you're just like tinkering with something. But yeah, so , it will get the deploy set up for you. And fly is not like Versace where they put like an outrageous amount of time and effort into the dx.

They're gonna get there eventually, but having preview deploys and stuff like that all integrated with GitHub, that's not a thing with FLY yet. But we have our own GitHub actions that are generated for you. So it will deploy your main branch to PR production automatically. It will deploy your dev branch to a staging environment.

And eventually I do plan on having uh, preview deploys for PRS as well. That's definitely something that's, Possible with fly. And so we'll do that eventually. But anyway, we're getting off of the guiding principle of minimizing setup friction. Cuz one of the other important parts of that is [00:11:00] while we do use services for things I don't want you to have to sign up for all those services before you can actually deploy to production.

So an example of this is we absolutely are using a service for email. But I don't want you to have to sign up for that before you can deploy to production. And so if you haven't set that up yet, it will just log the email to the console. And so you can go look at your logs and see what the email would've been, while you're just experimenting and testing and stuff.

And then when you're ready to really go then to production, then you sign up for the email and stuff like that. So that's one example. Like , we don't want to make you have to sign up for a bunch of stuff before you can actually get going.

Paul: That feels like a simple, it is a simple thing. It should log it out if the environment variable's not there, but like that set of friction is huge to getting people onto your ecosystem. So if I could just boot it up and it just works that's amazing to hear.

Kent: Yeah, 100%. And this is a pretty non-trivial app that you can go from zero to deployed in five minutes. Oh. Sometimes a deploy could take a little while, but yeah, 10 minutes max for sure.[00:12:00] And it's like I said, non-trivial. It has. Authentication, baked in and like all of that stuff too.

The next guiding principle is optimized for adaptability. So I feel really good about the opinions that I have made here. But product requirements are always changing and you might not be okay with like maybe you have a vendor. For email you already have an established relationship and so you need to swap the decision we've made for which service to use for another one.

Or maybe you do have to host on aws or something like that. Like you've got some weird requirements at your company. I want to make it so that it's pretty easy to swap out some of the opinions in there. And yeah that's another guiding principle. Right now the whole app is built into a Docker container.

So anywhere where you can ship Docker you can ship this. There are a couple of features that are reliant on some fly features, but those fly features are based on open source projects too. So you should be able to self-host that if you needed to. But you could also just not use those features.

So [00:13:00] the biggest one is multi-region. Support. So you can deploy to multiple instances along with your data, not just the app, but the data is also in those regions. And you're gonna need some infra specific stuff to make that data replication work. But if, if you have some weird requirements and one of those is not deployed to multiple regions in the world then you just don't use that feature.

And now it's really easy to. Adapt to your own requirements, so yeah.

Paul: , I remember we had the folks from Planet Scale on the podcast and they were talking about like the auto replication. Like Let's say I did want to contract out that service. I could plug that in and have my data follow where my deployment goes.

Kent: Yeah, you should be able to do that without too much trouble. We're using Prisma as our O r M and Prisma works with plant Scale. And so yeah, you just change your uh, source and you'd probably remove a couple of things cuz we're using light Fs for the SQL light database.

That's how the data replication works is with that fly feature. So yeah, you'd just remove those pieces. I think , [00:14:00] provided you don't have data to migrate yet you could make that change in 20 minutes pretty easily. I could make that change in five minutes.

, that would be pretty straightforward especially if you had experience with Planet Scale already. So yeah, . Another uh, guiding principle is there's only one way to do things. And so like I, I've built abstractions for a long time. If you have two APIs that look exactly the same then the question becomes okay, so which do I use and when?

And so now you need documentation and people use the wrong one in the wrong setting and stuff. And for sure there are different use cases. Like , we have caching built in and one cash is in memory, and one cash is in SQLite. So we, we do have two caches. So there are two ways to do something similar.

But there are like legitimate different use cases for those. And that's why we support them both. The point of this guiding principle is just the burden of proof has to be on. Why should we or how is this different? Like why should we do this? There's got to be a good reason to add another way to do something that's similar.

And then the last uh, guy named [00:15:00] principal so far I. I have made a couple additions to this since I first released it, but the last one is offline development. So I wanna make it so that you can build and work on the app a hundred percent offline, disconnected from any services., it's.

Really sad to me the state of the world as far as just having to be connected to 30 different services , to work on your app. And I understand especially when I was at PayPal yeah, I definitely needed to be connected to lots of these services. It was just too complex , to not but I think that we probably, if we'd started with the idea of that offline development is an important.

Thing, and we probably could have built it in such a way to make that possible. And I wish that we had, because the developer productivity just really improves when you're thinking about things from a working offline perspective. Now, this is not like your app should work offline.

I just mean that you as the developer. Working on your app, don't need an internet connection to work on the app. And this isn't just because like we [00:16:00] work a lot on airplanes, or I wanna work outside without an internet connection or whatever. It makes an impact on the speed of your end-to-end test.

It just makes things much easier to develop when the APIs aren't ready. If you're always thinking about how do I make this work offline? Than your developer productivity be is a lot better. So anyway, those are the guiding principles. We still haven't really gotten much into the tech, but I think that it's pretty important for people to understand like, if if if these goals align with something that you're interested in, then don't worry so much about the tech.

The tech will decisions will take care of themselves. The principles are I think, what is most important here.

Paul: So we got six guiding principles and I know we didn't get into the tech super deep, but I thought it gave us a good platform to start to understand. Why you might make some of the decisions, like why we might be using Remix, why we might be using Fly. Cuz fly is definitely not the number one choice for people when they go search up how to host my website.

But it has a lot of really compelling reasons for these guiding principles that you brought up. [00:17:00] Kent I'd love to double click a bit on the main. Web development framework, right? That you chose remix. Before we do that though, I just wanna remind our listeners that the podcast is brought to you by Log Rocket.

And Log Rocket will help you build web apps in a variety of different ways. If you choose to outsource one of those services and you wanna supercharge your bug finding process, spend more time building your app and less time digging through your console. Go ahead to log rocket.com, check it out. You can drop in a few lines of code.

Use powerful analytics and error tracking to build your app faster. So Kent, if we can talk a little bit about remix. Remix is an interesting web framework. I think we get like 50 50 division of people who use like remix and people who use Next. And then you got like the purists out there who don't wanna use anything for people who might be in the next JS world.

Who look at remix, it might feel like advanced almost. Cuz if you look it up, it's oh, this used to be a paid [00:18:00] framework. That's how remix started. It was a paid proprietary framework. Now it's open source and it uses a weird loader thing going on. If people are looking at the end, they're used to next JS land.

What are some words of comfort to, to try to drive home this idea of the tech doesn't matter. You'll be okay. Everything can still be made.

Kent: Yeah, sure. So I would say push against the weird moniker there and say it more. Unfamiliar which is fine. , there's an important difference between things which are easy versus hard and things which are familiar versus unfamiliar. And I would say that familiarity is uh, something that you can develop with with these APIs.

Yeah if somebody's experienced with Next, I'll just mention we do have a blog post that we can read on the remix blog that does a comparison between Remix and Next that the TLDR of that is remix is better in every way. But but you can look into it. It's a very uh, deep dive both on the user experience that Remix offers as well as the developer experience.

And because I'm talking to developers here, I'll just say Quick [00:19:00] example of why remix is so great is from the DX perspective is this blog post breaks down a comparison of the same e-commerce store that next built and remix just made a its own. Implementation of where in next the implementation of the Shopify integration was almost 8,000 lines of code.

And in remix it was 600. So like number of lines of code is, not always the perfect metric for dx, but I think that's a pretty good tell. Um,

Paul: When is that S sizeable?

Kent: Yeah. Yeah, exactly. So yeah you'll like it a lot. Give remix a shot. It is a really awesome experience and I know a lot of people are excited about React server components and everything, and that's next.

And there are a lot of foots with server components, so just beware. But Remix is actively working on Implementing React server components without the foot guns. I'm looking forward to seeing what they have to offer there. So yeah, the decision to use remix for me though was Ryan and Michael were building it [00:20:00] and showing me things and I was very impressed.

I always look at the foundation and if the foundation is solid, then the features that it's missing, I don't really care too much about. Those will come eventually and I can build them myself. It's easy to build a house on a solid foundation. It's very problematic if you build it on one with cracks.

And so I felt really good about the foundation. So as soon as they released it for developer preview as a paid software I bought it immediately. Built my website with it. I loved it. They ended up hiring me to work on The uh, developer experience and documentation. And I ran remix comp and worked on other community related things.

Then I left to go full-time on Epic Web Dev where I'm teaching people how to build Epic Stack apps. Basically and uh, now that's, yeah, my full-time thing. So I have no stock in Shopify or any Shopify acquired remix and I have no financial incentive. Um, As far as uh, promoting Remix is concerned.

I just literally think that it's the best framework for building web apps and and so that's why [00:21:00] I selected it for Epic Stack.

Paul: I want to ask you about the future of Epic Stack, but right before we get into that, could you just tell me like what is something about the foundation? I'm curious. Cause I have not personally gift, I'd say like the. The foundational components between Next and Remix. I don't have the experience as that core web dev to do this.

What are some observations in the foundation of Remix that really made you feel comfortable 

to 

proceed in this? 

Kent: Yeah, that's great. So one really big one is that everything comes back to the URL in remix. In typical React apps, we like to co-locate our data with the UI that needs the data just makes things so much easier. that was one of the main value propositions of GraphQL was being able to co-locate your data requirements with the components that require them.

And that's really useful. The problem with that is you have to render before you can know what data you need because you're putting all of that inside of use effects and stuff. Or if you're using React Query, it's the same thing. You don't know what data you need until you render and [00:22:00] you even have to go get the data before you know what images you need.

And you're instantly sticking yourself on this cascading waterfall effect where you have Go fetch the component code, then render the component. Now go fetch the data and then render the image and now go fetch the image. And it just leads to a really poor user experience with lots of loading spinners.

And so remix instead says, no, everything comes back to the url. So here's our components that we need for this url, and here's the data we need for this U url. Here's the CSS we need for this URL here. Even if you have enough information, you can even say, here's the images we need for this url.

And because it's server rendered Yeah, you absolutely do get that. And so by focusing on that, you get a lot of really awesome things. And not only that, but also nested routing, which next is adopted and everybody else is doing as well because it's such a good idea. And remix didn't invent nested routing to be clear, but they made it popular.

By making everything attached to the URL and then supporting nested routing, so you can have [00:23:00] like smaller segments of the page be associated to that URL segment. You make it really nice for the user experience because you can prefetch things, if you're only changing a sub route, you can only load the data for that sub route.

Nothing else has changed. So you do a lot of really great UX optimizations, but then you also get a lot of really great DX optimizations because now you don't have to worry about doing some sort of use effect and like handling loading states and, and what happens if there's an error or whatever.

And remix actually has a lot more power. Because you're doing all of your data fetching and requirements through remix. And so because it's your router and your bundler and your data fetching library, it's able to optimize that really nicely for you. So you literally just have this loader function that runs on the server, and then you have your UI that runs in the server and the client.

You don't have to worry about keeping those things connected. One of the biggest challenges in web is this network chasm that we have between the client and the server. And normally we're just shooting grappling [00:24:00] hooks across that chasm, like trying to get that, with the spec requests and stuff.

And remakes makes it feel like the chasm doesn't exist. And so , that was one of the big things that I really appreciated about Remix and that I saw that and it was like there's a solid foundation right there.

Paul: If we look to the future of Epic Stack Kent, are you hoping that people are gonna sh group into the Mindshare here and increase Plugability, or are you really trying to keep it, you as the developer and keep it tidy and trued up along the edges? Yeah. What's your opinion on that?

Kent: Yeah, that's a great question. I have mixed feelings about this because the things die by committee, and I definitely plan on being the beneville dictator thing here where I just decide everything., I definitely do want people's input and feedback because there are some things that I even in my time at PayPal and things that I had limited exposure to or there are new.

Pieces of tech that I haven't kept up on for solving various problems. And so I'm definitely [00:25:00] interested in people's opinions and experience. But yeah I pretty much want to be the one evaluating those solutions. I feel like I've got a pretty solid. Understanding of constraints around these applications and can evaluate different things really well and make a decision, even if I don't have personal experience with that quite yet.

I can foresee the problems that could come based on the different architectures of things. And so yeah, I do plan on being the one to make all the decisions here, but I also recognize the value of other people's voices and I've been doing open source for a long time, so I've got dead open source projects in my past that I wish that still had life because I just didn't pay too much attention to the community or at least building contributors to those.

So I do want to have people participating and they have we've had a lot of contributors to the Epic stack already.. 27 people have contributed in some way to the code of the Epic stack. And there are more people who have contributed questions and answers and stuff too.

Paul: And , what are your plans for the [00:26:00] next maybe three to six months? The next one to two quarters?

Kent: We've got a lot of things done. Like I said, there's built-in authentication, there's role-based permissions. There's built-in image hosting and caching and end-to-end tests are all implemented. And the lower level tests and tight script and forms progressively enhanced it.

Fully type, safe mutations. All of that stuff is built in. It's awesome.

Paul: It's not just authentication, It's role based. 

Kent: Yeah. Like you've got admins and, and and stuff. , there are some routes that are admin only. So we have a page where you can manage the cash as well if you're an admin. So yeah it's like this is legit folks.

, but there's still a lot more left to do. And some things that I really want to. Support out of the box, our internationalization image optimization and having that caching. So basically like a cloudinary but built in which would of course be easily swap out. Like you could swap that out with Cloudinary if that's what you wanted to do.

But I want to have something that's built in I want feature flags. And error monitoring and e-commerce. Maybe, probably an example with [00:27:00] e-commerce, with Stripe. I don't think that needs to be built in, but at least an example. And then analytics and, stuff like that that I think we still have a lot to do.

But the biggest thing that I need to do is um, the education piece of this, and that's what Epic WebDev is all about. So the cool thing is that the Epic stack isn't doing. Anything that's like completely proprietary or anything you learn the epic stack, you can apply your learnings to whatever you're working on.

Most people aren't generating new projects every day. They're like just building on existing projects and referencing things to make their project better. And that's the primary audience for the Epic stack. Even though the setting things up is also a pretty important aspect of it, but I do want to have a really good reference for people.

So anyway, epic Web. It is intended to teach how to build awesome applications with the Epic stack. And my hope is that this is very well applied regardless of whether you're using the Epic stack. So anyway, I'm gonna be putting together a bunch of workshops and [00:28:00] videos and things that people can consume on Epic Web dev that will both be paid and free.

I need to. , make this sustainable. So yeah, there will be a paid aspect to this as what of course. But the documentation and examples and things like that are so the end, that's a pretty big task for us to

Paul: And that's Epic Web Dev. Okay. Epic Web Dev.

Kent: I wanna make you all epic web devs.

Paul: Hey, , that rolls off the tongue. That's

Kent: Yeah. Yeah, it does. It's great.

Paul: Ken if people wanted to not just keep up with the stack, but just your personal musings. Are you on Twitter? Do you broadcast to the world?

Kent: Yeah. I livestream pretty regularly on YouTube and just search of Kent, see Don's on YouTube. And I'm on Twitter all the time. I'm Kent, see Don's there. My website I publish blog posts occasionally, Kent see dons.com. And I just published one that's a little bit fiery, called Stop Being a Junior.

Just giving advice for people to, stop thinking of themselves as juniors, like it's time to. Grow up I [00:29:00] guess,

Paul: Take ownership.

Kent: but yeah. So you can check that out. And then the epic web.dev is where I'm gonna be putting a lot more educational stuff, both free and paid of videos and podcasts and my writings As well.

I also do have a podcast on my personal website that's like a call in podcast where you record yourself asking a question for a couple minutes and then I respond with my answer and that turns into a podcast episode. Feel free to join my podcast sometime. I also have office hours every Thursday, so feel free to join me for that.

And it's just like a Zoom call that's streamed to YouTube. If you have any questions or whatever, that's the best place

Paul: Office hours with Professor duds, show up, be there. Be square folks. Kent, it was a pleasure having you on and learning about the , epic stack, especially through the lens of the guiding principles. I feel like it really helped frame the ethos about what you're trying to do and how you're trying to do it.

And yeah, hopefully a lot of people will go check it out , it's on GitHub if they search up in the GitHub topics. Epic stack, I assume. Awesome. [00:30:00] It was a pleasure having you, Kent. Thank you for your time.

Kent: Thank you so much.