The Epic Stack

Hi everyone, my name is Kent C. Dodds and I'm so excited to talk with you about the Epic stack. Before I do, I just want to give a shout out to Epic web dev. By the time you're watching this, Epic web dev will be available and if you haven't seen it yet, you should definitely take a look. It's everything you need to know about building full stack applications. It's awesome. Give it a look.

Alright, I'm going to start out with the content warning. There's sadness ahead. This is something that happened recently, not far from my house. Well, far enough. But, yeah it's really sad actually. To be clear, nobody was harmed in this event. They knew that this was going to happen long before it did. But basically what happened is a company put a bunch of dirt up against the side of a hill and it didn't quite work out. The dirt fell from under the house and a house and a half fell down the hill which is just so awful. I can only imagine how terrible this would have been. What's kind of ironic or sad about this is that this is the name of the company that built the home, Designed for Life. Yeah the short life I guess. This talk is about the fact that we are terrified of making a mistake like this. A mistake where the likelihood is really low, you know, it's not everyday that houses fall over like this, but the risk is really high. If this sort of thing happens, then we've got a serious problem. And so I want to talk with you about paralyzing decisions or these sorts of decisions where, like I said, likelihood is low but risk is really high.

So let's talk about modern web development, how awesome it is. It's fantastic. There are so many great tools available for us to build awesome things. Unfortunately it's also exhausting. I don't know how many of you still remember back in like 2015 when everybody was talking about JavaScript fatigue and everything. Yeah, it's exhausting. There are lots of great tools available but, yeah, exhausting.

This was exhausting, putting this slide together, there are just so many tools. And some of these tools you wouldn't use together, like some of these tools are like competitors to each other or whatever. You might use them together if you're migrating from one to another.

But the fact is, these logos represent something that people are building, that they put at least enough time in to make the logo in the first place. And there's a lot that we have to do as web developers. Now, I think we're missing one. I just realized. Oh, no, that's right. There it is. Ha ha. My favorite, Remix, is amazing, super huge fan of Remix. But even still, all these tools to build a web application, it's exhausting, it really is.

So, here's the real talk. Almost whatever you choose will probably be fine. You could put all these tools up on a dartboard and throw a dart at it, blindfold it, and whatever it landed on, you go with that tool, you'll probably be fine using that tool. And you know it. We all know it. We like to think that our project is the snowflake that needs to be like exactly with the perfect set of tools. Otherwise, it will never succeed. But for most of us, it really doesn't matter that much which tool we use.

And yet, we are indecisive. We can't decide on which of these tools to use even though it actually doesn't matter all that much. So on the one hand, we know that it will probably be fine. But on the other hand, we have to live with this. And we have to worry about this type of an experience, where what if I do make the wrong decision? And now I'm left with this situation where I have to rebuild my app or I have to migrate my app, and it's just an enormous amount of pain. So we're terrified of making the wrong choice, even though we know that the right choice, there isn't really a right choice that we have so many options, but choosing any of them will probably be fine. Still, we have to live with it. We're worried about it. And then once you do decide, now you have to get everybody aligned, like we say, okay, we're going to do it this way. And then somebody decides, oh, I'm going to do it this way.

And now you've got three combo box implementations in your app is literally happened to me in the past. That's where downshift came from. And so it can be a real challenge to keep everybody on the same page once you have made the decisions, and then you make the decisions, you have to wire things together. There's not not a single tool that does everything. And so yeah, wiring things together doesn't always work out perfectly.

Well, all of this is just a big distraction from our desire to just ship, to engage. We want to ship our software. And all of this is distracting us from doing that. So here's the deal. This is a more real talk for you. I've been around long enough where I see a problem and I feel like I've got it handled. I know exactly what to do. I can execute and and things will go well. This all has, it comes from the opinions that I have developed over time and not everybody appreciates or likes my opinions. I'm not going to necessarily win a popularity contest on all of my opinions but the fact is that whatever you choose will probably be fine. And my opinions I feel like are pretty well-based in fact. I've worked at small companies and shipped apps to just a couple people and I've worked at huge companies and shipped apps to millions of people. I feel like I have a pretty good sense for what makes a really great set of tools to use for an app.

So that's why I'm excited to introduce to you an opinionated project starter and reference called the Epic Stack. I've been working on this for a couple of months and it's been awesome. People are actually using the Epic Stack to build applications that they're being paid to work on. It is a project starter. Right now it's a remixed stack, but in the future I'll put together my own CLI for this. But it works really great. You just run this and poof, you've got the Epic Stack. But it's also a reference implementation. So you go to the GitHub repo and it's a full stack application built with all these different tools with really, really great docs. In fact, Epic Web Dev that I talked about at the beginning of the talk is basically where the documentation for the Epic Stack is going to be, both in the free version as well as in paid version of the docs or of the Epic Web Workshop series. So I think most people are going to get most value out of the Epic Stack as a reference implementation because most of us aren't building new apps every day. And we're trying to evolve our existing apps.

And so you can think, OK, so how did Kent do server rendered time zones? Or how did Kent do, you know, two-factor authentication? Whatever it is that you're trying to work on, you can go reference the Epic Stack and see what's a good way to do this and follow that in your own project.

Another thing that I've put together is decision documents. So while we have a lot of decisions to make in everything, there's analysis paralysis and all of that, the decision documents are super helpful in helping you understand the things that I considered when I made big decisions, like why are we using this particular email service provider, or why are we going with this format for our native ESM modules and various other things, you can take a look in the decision documents. Which I think is really quite helpful because it helps you get a pretty good understanding of the why behind decisions that are being made.

So another awesome thing about the Epic Stack is the guiding principles. So these are the things that kind of guide the direction of the project. To be clear, I am the benevolent dictator of this project, and so the guiding principles are pretty much how I lead the project. But hopefully, if you align on these guiding principles, then it will align pretty well on what the ultimate decisions of the stack are. So first, limit services. I think that it's important for us to own our destiny. And that can be really difficult if we're using a lot of different services. And this isn't just third party services, which of course, that definitely factors in. But this is even our own services. Every single service that you add to your application increases complexity. Now, sometimes that is going to reduce or solve other problems. And so it's worth that complexity. But especially if you're just getting started on a new project or for the vast majority of projects that we all work on. You can have everything running on it in a single box and it will work just fine. And as long as that box is managed for you, because I don't want to manage a box, a virtual machine or anything. So as long as that VM is managed for you, then just say, here's my thing and run it and it's all together in one. You don't have as much trickery when it comes to deployments and different things like that. And costs are a lot cheaper as well. So that's one of the guiding principles, is to limit services. There has to be a real justifiable reason when you introduce a service. Now, of course, we do have some services that you have to use. I'm not hosting this thing in a NAS in my closet or something. But yeah, we want to limit that as kind of the guiding principle. The next thing is to include only the most common use cases. So the Epic Stack is a reference implementation. So we do have features in the Epic Stack that you probably won't have in your own application.

But those features are necessary to demonstrate like user authentication and permissions and stuff like that. And so we do have to include some things, but we don't have to include everything. And so the idea is we want to limit the number of things that are included when you bootstrap the app. So you reduce the number of things you remove.

Along with that, if you are just getting up and going, you don't want to spend the first hour of your time signing up for a bunch of different services and setting keys and all that stuff. So we want to minimize the setup friction. So for though we are using services for some things, I want to make sure that you don't have to set up those services just to get things deployed. You can set those things up later. And so that's another guiding principle.

We want to optimize for adaptability. So the only consistent thing in this industry is the fact that nothing's consistent and that it changes a lot. And so we want to make it so that you can pivot around the different decisions that need to be made and product changes and all of that stuff. And so while I do feel very confident in the opinions that I have, I want to make it so that it's easy for you to swap out different things. If you do want to use a service for this thing or whatever, make that as easy as possible. And then only one way to do something. So we want to reduce that bifurcation of approaches for things. And so, yeah, if somebody wants to bring in some tool, then we either need to replace the tool that's already solving that problem or we just say, no, we're not going to bring that tool in. So that's another guiding principle. And then finally, offline development. I feel like being able to develop offline is awesome. It's being able to go up into the mountains and have no connection at all and still be able to work on my project. That's cool. But that's not why this is important to me. This is important to me because I think that it makes you more resilient to your dependencies, either going down. Being unavailable, being incomplete. All of that. So the idea behind the Epic stack is that you can develop offline. And that's that's another guiding principle.

So at this point, you're probably like, yeah, that all sounds great, Ken, but what are the decisions you made? What are those opinions? Please tell me. What are these opinions that you've made? I want to see if we line up on our opinions.

So here's what the Epic Stack looks like. It looks like today. First of all, it's using Remix, the best framework in the world. Huge, super fan of Remix. And of course, Remix uses React. So we're using React as well. Super fan of React.

We are using some services. We need to use services to like host it and different things like that. So we're using Fly to I.O. Fly actually comes with Grafana and Sentry. And so we're using those services as well for production monitoring and everything. Using GitHub Actions to deploy, we will deploy to both a production environment and staging environment. And then we're using Resend for sending emails. I would love to just send an email right from your box. But that just is not a thing that you can do if you want your emails to get to their destination. It's a really sad state of affairs. But you can actually take a look at the decision document to get an idea of like, why are we using an email service provider? And in fact, I started with a different email service provider and changed to Resend, and I have a decision document about that change as well.

And then Docker. I know that some of you were kind of like shaking in your boots a little bit when you saw the Docker logo. But to be clear, you probably won't need to touch this. This is a generated file for you. And if you ever do need to change it, you'll be really glad that you can change it. It's really, really powerful. So those are some of the things we're using. Also using Node.js and Express. Node.js is just awesome, super big fan. Bund is exciting and things and maybe eventually I'll move over to Bund. But Node is really, really battle tested and it's awesome. Express also one of those that I'm definitely willing to look into another alternative, but it's still a really battle tested framework and stuff.

Honestly, we actually don't use Express a whole lot. There's a single file that uses Express and then everything else is remixed, so it doesn't make a huge difference. And migrating to something else would be a pretty like an afternoon sort of thing probably.

Then of course we're using Tailwind and also Post-CSS for those situations where you don't want to use Tailwind or you just want to write regular CSS, but Tailwind is fabulous. It's awesome. All built in.

We're using SQLite for the database and Prisma for accessing it. It's awesome. This comes with a like permission schema, user schema, password hashing, and images, like all sorts of things. SQLite is actually really, really powerful. And I know it kind of has this baggage of like, Oh, that's just for mobile apps or, Oh, that's just for toys. Oh, that's just for testing. No, I've been using it in production for years. It is awesome. So SQLite also allows us to reduce the number of services that we're using. And so your reliability of your database is going to be awesome. And because it's on disc it, there's zero latency. And so it's really, really fast. The like the, what's it called the inquiry problem. It's not really a problem with SQLlite it can store like petabytes of data. It's, it's amazing. It's just ridiculous. What SQLlite is capable of.

We're using Xod and Conform that combination gives us progressively enhanced type-safe forms. That is just so amazing. So huge, huge fan of Xod and Conform. Using a Radex for components and Shad CN for really nice nicely styled components. It's awesome. Put those together. And then we have all the testing tools.

You might imagine testing library, v-test, playwrights, FakerJS, MSW, all of that stuff. Table stake stuff. And then all the typical tools you'd expect, prettier TypeScript, NPM and ESLint. So awesome set of tools. And there's a lot more to this. So like just a silly number of things. Feel free to pause the video and read all of this stuff.

And there's more coming too. We also have examples, lots of examples of using the epoch stack with various other technologies and stuff. So give these examples a look. There's a ton of stuff that that we can do and on top of that, definitely looking for other examples. So if you work at a company that sells stuff to developers or something, put together an example of the epic stack with your thing, that'd be cool. So one thing that's unlikely to happen is more than one way to do the same thing. So that's what examples are for. You can do a lot of, you know, show a lot of different ways to use the epic stack or adapt the epic stack to different things. So if you don't like the opinions of the epic stack, that's totally fine. You can fork it and build your own version of the epic stack and then create new projects based on that.

So one thing that you can do to help with the epic stacks go to get hub right now and go star it. And that actually does help. I know that it seems like a vanity metric, but actually stars do matter. People do look at those stars and they are interested in seeing repos that have a lot of stars. So stars are helpful. Help is always welcome, especially examples. That's something that's relatively easy for people to throw together. And then if it's a really, really great idea then, and you can demonstrate that in an example, then potentially we could bring it into core. So we're also active on discussions and Discord. So come and chat over there. It's awesome. And yeah, I just want to wrap up with the last two minutes I've got and talking about something. I was really struggling with something, making some decisions.

And the decision I was struggling to make was what to do with Epic Web Dev. And because I just realized that like people don't know that they're a customer of Epic Web Dev, like they, they see Epic Web Dev and they're like, well yeah, I'm a web dev, but do like, am I, you know, does this apply to me? Because the web is just so broad with testing JavaScript. It was obvious. I want to test JavaScript, boom, testing JavaScript.com, with Epic React. Yeah. I want to be a react developer. Let me go do that. Epic Web was just like too broad.

And so, I realized that what Epic Web Dev offers people is a pathway out of this, out of the, oh man, this is a huge risk, but a low likelihood decision. But like, I'm, I'm paralyzed by, how challenging this decision is. And so what Epic Web is is it's the documentation for the Epic Stack. The Epic Stack solves that analysis, paralysis problem in Epic Web is how I teach you how to use the Epic Stack.

This is how I keep the Epic Stack sustainable for myself. And so Epic Web is comprised of a lot of free material teaching about the Epic Stack and how to build Epic Web applications, full stack apps. And it's also comprised of a series of workshops that you can go and this first volume that I've just released is basically how to build the Epic Stack. So you really get a solid understanding. And even if you're not using the Epic Stack, you'll have a much better grasp of the underlying technologies that you will probably use in your own web applications by building the Epic Stack. And so I hope that you give Epic Web a look. The Epic Stack is where we can give you a firm foundation. That's my goal for the Epic Stack. So I actually just have one more thing and then I'm all done. And this is that one more thing. You are awesome. Thank you so much.