Modern web development is fantastic. There are so many great tools available!

Modern web development is exhausting. There are so many great tools available!

Each of these sentiments is true. What’s great is that most of the time, it’s hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps.

Despite this, engineers consistently struggle with 

. Nobody likes the feeling of having to make a decision they’ll have to live with for the foreseeable future and find out it was the wrong one. Like a hungry person getting hungrier looking over menu that’s too long and full of great options, engineers find themselves guessing and second guessing our technology choices.

On top of that, getting team of engineers running the same direction with the chosen technology can be a big challenge. There are numerous considerations, existing skills, training for new skills, the hiring pool, personal preferences and experience, and more.

Oh, and then once you’ve finally selected a web framework, UI library, testing framework, hosting provider, etc. etc. you have to wire everything together before any meaningful work can get done.

 from what we’re really trying to accomplish here: 

I’ve been developing modern web applications big and small for nearly a decade. In that time, I’ve worked all over the stack. Significant technical decisions I’ve made are still in use at my previous companies (like PayPal). I’ve also made a number of technical decisions that didn’t pan out very well at all and I had to pay the price.

With the help of my team, I’ve shipped web applications to millions of users all over the world as well as smaller internal apps to a handful of stakeholders. I have a solid grip on what it takes to ship excellent user experiences and make choices that keep developer velocity (and morale) high.

That’s why I’ve decided to encode my experience on how to build excellent modern web applications into 

 that allows teams to ship their ideas to production faster and on a more stable foundation. And it’s called “The Epic Stack”:

The primary goal of the Epic Stack is to help your team get over analysis paralysis by giving you solid opinions for technologies to use to build your web application. The Epic Stack is really two things:

For those of you starting a new project, you can use the 

 CLI custom stacks feature to bootstrap your app with 

npx create-remix@latest --typescript --install --template epicweb-dev/epic-stack

But most people don't startup their computer every day and start a new project. Most of us work on an existing app. For those folks, the Epic Stack can be a great reference for configuring tools and integrating with solid libraries and services. 

 can also serve as a good place to find good arguments for the decisions and trade-offs made.

There’s far too much for us to talk about in a single blog post, so I’ll encourage you to dive into the 

, but let’s get a high-level view of what you get when you use or follow The Epic Stack.

 If we can reasonably build, deploy, maintain it ourselves, do it. This saves on cost and reduces complexity.

 As a project generator, it is expected that some code will necessarily be deleted, but implementing support for every possible type of feature is literally impossible. 

, so to demonstrate a feature or give an example, put that in the docs instead of in the starter app.

 Try to keep the amount of time it takes to get an app to production as small as possible. If a service is necessary, see if we can defer signup for that service until its services are actually required. Additionally, while the target audience for this stack is apps that need scale you have to pay for, we try to fit within the free tier of any services used during the exploration phase.

 While we feel great about our opinions, ever-changing product requirements sometimes necessitate swapping trade-offs. So while we try to keep things simple, we want to ensure teams using the Epic Stack are able to adapt by switching between third party services to custom-built services and vice-versa.

With that context, here are a few things you get today:

Multi-region, distributed, production-ready 

 with testing and deploy on merge for both production and staging environments

 and forgot password/password reset support.

Progressively Enhanced and fully type safe forms with 

: Both in-memory and SQLite-based (with 

An excellent, customizable component library with 

And that’s what we have today, here are some things that will likely find their way into the Epic Stack in the future:

Light/Dark/System mode (without a flash of incorrect theme)

Documentation on production data seeding process

A list of features is fine, but really what you’re getting out of this is a break from analysis paralysis. You get to ship faster on top a solid selection of technologies and tools.

Additionally, my goal is to make the Epic Stack second-to-none with regard to learning resources so your entire team can all get up-to-speed on your stack quickly. And having your entire team on the same page with regard to your stack is invaluable.

 will be all about: How your team can take the Epic Stack foundation and build a quality application on top of it.

After all the time I’ve spent building web applications and learning from engineers with more experience than myself, I feel extremely confident that the Epic Stack will help tons of engineering teams focus on their core offering, move fast, and build excellent user experiences. I hope you give it a shot. Please join the community by participating in 

Introducing an opinionated project starter that enables web development teams to ship their ideas to production more efficiently.

The Epic Stack

There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all. I’m calling it “full stack components” and it allows me to colocate the code for my UI components with the backend code they need to function. In the same file.

Let’s first start with the first time I’ve ever seen such a strong marriage between the UI and backend. Here’s what it’s like to create a web page in Remix:

I’m going to just gloss over how awesome this is from a 

 perspective and instead focus on how nice it is that the backend and frontend code for this user experience is in the 

 Remix enables this thanks to its compiler and router.

 runs on the server (only) and is responsible for getting our data. Remix gets what we return from that into our UI (which runs on both the server and the client). The 

 runs on the server (only) and is responsible for handling the user’s form submission and can either return a response our UI uses (for example, error messages), or a redirect to a new page.

But, not everything we build that requires backend code is a whole page. In fact, a lot of what we build are components that are used within other pages. The Twitter like button is a good example of this:

Twitter Like button getting clicked

That twitter like button appears many times on many pages. Normally the way we’ve built components like that is through a code path that involves click event handlers, fetch requests (hopefully thinking about errors, optimistic UI/pending states, race conditions, etc.), state updates, and then also the backend portion which would be an “API route” to handle actually updating the data in a database.

In my experience, doing all of that involved sometimes a half dozen files or more and often two repos (and sometimes multiple programming languages). It’s a lot of work to get that all working together properly!

With Full Stack Components in Remix, you can do all of that in a single file thanks to Remix’s 

 feature. Let’s build a Full Stack Component together. For this example, I’m going to use a feature I built for 

 of the “Fakebooks” example app demonstrated on 

. We’re going to build this component which is used on the “create invoice” route:

New invoice page showing customer combobox listing options as a query is typed

First, let’s make the resource route. You can put this file anywhere in the 

 directory. For me, I like to put it under 

 directory, but feel free to stick it wherever makes sense under 

. To make a resource route, all you need to do is export a 

s data and doesn’t actually need to submit anything. So, let’s make a super simple loader to start with:

Great, with that, let’s run the dev server and open up the route 

Great! We now have an “endpoint” we can call to make requests. Let’s fill that out to actually search customers:

This is a publicly accessible URL but our customer data should be private, so we need to secure it via 

 which will check that the user making the request is authenticated.

 request, the user input will be provided via the URL search params on the request, so we grab that (and also validate that the query is a string as expected).

We retrieve matching customers from the database with 

 and send that back in our JSON response.

Now if we hit that URL again with a query param 

Santa Monica

Stankonia

Wide Open Spaces

Sweet! Now all we need is a component that we can use to hit this endpoint.

 hook that our component can use to communicate with resource route and we can define that component anywhere we like. I had a real “aha 💡” moment when I realized that there’s nothing stopping you from defining and even exporting extra stuff from Remix routes. I don’t recommend making a big habit out of importing/exporting things between routes, but this is one very powerful exception!

I’m going to just give you all the React/JSX stuff because it’s really not that important for what we’re discussing in this post. So here’s the start to the UI component:

We’ve got 🐨 Kody the Koala in there showing the specific touch-points that are of particular interest to what we’re building. A few things to note:

 to build our combobox (a great set of hooks and components for building accessible UIs like this that I built when I was at PayPal).

 to style stuff in here because it’s amazing and it also helps give us that “Full” part of “Full Stack Component” by including the styling within this component as well.

Let’s follow Kody’s instructions and add 

 in here to make a GET request to our resource route. First, let’s create the 

Great, so now, all we have to do is call the 

. As I said, normally this involves a lot of work, but with Remix’s 

 handling race conditions and resubmissions for us automatically, it’s actually pretty simple. Whenever the user types, our 

 callback will get called and we can trigger 

 is set to reference the file that we’re currently in and the 

 so Remix on the server will route this request to the 

As far as “functional” goes, we’re finished! But we do still have a bit of work to do to make the experience great.

For some of our users, this will be enough, but depending on network conditions over which we have no control, it’s possible this request could take some time. So let’s add pending UI.

, we’ve got 🐨 telling us we should render a spinner. Here’s a spinner component you can use

So let’s render that next to the input:

And now, how are we going to determine the 

 value? 🐨 is sitter there next to the 

 declaration inviting us to determine that value there. With 

, we’re given everything we need to know the current state of the network requests going on for our Full Stack Component. 

. In our case, we’re safe to say that if that state is not 

That’s great, but it can lead to a flash of loading state. We’ll leave it like that for now though so you can play around with it.

This part is nothing special. We simply import the component and render it. If you open up 

 component, you’ll find 🐨 waiting there with 

 ready for you. You’ll also need to add an import at the top: 

import { CustomerCombobox } from '~/routes/resources/customers'

 prop and things are outside the scope of this post, but feel free to poke around if you’d like.

With the UI rendered, the whole thing is now functional! But we do have one small issue I want to address first. In the 

, I want you to add a bit of code to slowdown the request to simulate a slower network:

 as our timeout time, that slows it down just enough to be a pretty fast network, but not instant. Probably pretty close to the fastest experience most people would have in a real world situation. Here’s what our loading experience looks like with that:

Shows the customer combobox with a spinner that flashes for a few milliseconds

Notice that our loading spinner flashes with every character I type. That’s not great. I actually was bothered about this with my global loading indicator for 

 to solve this very issue! So, let’s add that to our 

What this is doing is it says: “Here’s a boolean, whenever it changes to 

, I want you to continue to give me back 

 unless it’s been true for 150ms. If you ever do return 

 for at least 500ms, even if what I gave you changes to 

.” I know it sounds a bit confusing at first, but read that through a few more times and you’ll get it I promise. Feel free to play around with those numbers a bit if you like.

In any case, doing this solves our issue!

Customer combobox showing a list of customers and no spinner shown

On top of this, if we increase that timeout delay in our 

Customer combobox with customers showing as a query is typed and a spinner being displayed

Here’s the finished version of our Full Stack Component:

I love how the integration points are pretty minimal here, so I’ve highlighted those lines above.

Remix allows me to colocate my UI and backend code for more than just full page routes, but also individual components. I’ve been loving working with components this way because it means that I can keep all the complexity in one place and drastically reduce the amount of indirection involved in creating complex components like this.

You may have noticed the lack of "debounce" on this. Most of the time I've built components like this, I've had to add a debounce so I don't send a request as soon as the user types. Sometimes this is useful to reduce load on the server, but if I'm being honest, the primary reason I did it was because I wasn't handling race conditions properly and sometimes responses would return out of order and my results were busted. With Remix's 

, I don't have to worry about that anymore and it's just so nice!

We didn’t get a chance to see this in action in our tutorial today, but if the component were to perform a mutation (like marking a chat message as read) then Remix would automatically revalidate the data on the page so the bell icon showing a number of notifications would update without us having to think about it (shout-out to folks who remember 

P.S. In the tweet situation we started with, we could take the pending state even further to optimistic UI which is also awesome. If you want to learn more about how to do 

There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all.

Full Stack Components

TypeScript is an enormous part of the web industry. And there’s a good reason for this. It’s amazing. And I’m not just talking about this:

I mean, that’s cool and all, but what I’m talking about is code that’s more like this:

A type that flows throughout the entire program (including between the frontend and backend). In the real world this is how it works and it can be a terrifying prospect to decide one day that you want to turn that “Seats Left” field into a combination of “Total Seats” and “Sold Seats” fields. Without types guiding you through that refactor you’re gonna have a hard time. I sure hope you have some solid unit tests.

But I don’t want to spend this article convincing you how great types in JavaScript are. Instead, I want to share my excitement about how great end-to-end type safety has been and show you how you can accomplish it for yourself in your own applications.

First, what I mean by end-to-end type safety, I’m talking about having type safety from the database, through the backend code, all the way to the UI and back again. Now, I realize that everyone’s in different circumstances. You may not have control over your database. When I was at PayPal, I consumed a dozen services built by different teams. I never touched a database directly. So I understand if getting true end-to-end type safety may require collaboration. But hopefully I can help get you on the right track to get as far as possible in your own situation.

The main thing that makes end-to-end type safety difficult is simple: 

The secret to fully typed web apps is typing the boundaries.

In the web, we have a lot of boundaries. Some of these you may have in mind, and others you may not consider. Here are a few examples of boundaries you’ll encounter on the web:

There are plenty more examples, but these are some common boundaries you’ll run into. Some boundaries we have here are (there are more):

 to be 100% certain that what you’re getting back from a boundary is what you expect. This bears repeating: It is 

 You can certainly “make TypeScript happy” by throwing around a 

 type cast and whatever, but you’re just hiding the problem there. The file could have changed out from under you by another process, the API could have changed, the user could have modified the DOM manually for goodness sake. There’s just no way to know for certain that the result that came to you across that boundary is what you expected it to be.

Write type guards/type assertion functions

Use a tool that generates the types (gives you 99% confidence)

Help inform TypeScript of your convention/configuration

So, let’s take a look using these strategies to get end to end type safety by addressing the boundaries of web apps.

 way to make sure what you got across the boundary is what you expected. You literally write code to check it! Here’s a simple example of a type guard:

At this point, some of you who are annoyed by having to “appease” the TypeScript compiler. If you’re so positive that 

 will be what you expect, then just throw an error (it’ll be more helpful than the error you’d get if you ignored this potential problem anyway).

There’s a handy utility I use in almost all my projects to make this slightly nicer on the eyes:

 function takes a value, and if the value is falsy then the invariant function will throw. If the value is truthy, then the function will not throw.

Having to add the extra code is annoying. This is just a tricky problem because TypeScript doesn’t know your conventions or config. That said, maybe we could let TypeScript know about our conventions and config to help it out a bit. Here are a few projects working on this problem:

 both generate types based on your Remix config/conventional routes (we’ll talk about this more later)

) have access to the routes you’ve defined (effectively informing TypeScript of your config which is another workaround we’ll get to).

This is just an example from a router perspective, which is addressing the URL boundary to your application, but the idea of teaching TypeScript your conventions can apply to other areas as well.

Let’s check out another more complex example of a type guard:

Seems like a lot of work, even for a relatively simple type. Imagine a more real-world complex type! If you’re doing this a lot, you may find a tool like 

My biggest concern with zod (why I don’t use it all the time) is the bundle size is quite large (

 at the time of this writing). But if you’re using it only on the server or you’re going to benefit a lot from it then it could be worth that cost.

One tool taking advantage of zod to help a great deal with fully typed web apps is 

 which shares types defined with zod on the server to client-side code to give you type safety across the network boundary. As I use Remix I don't personally use tRPC (though you definitely can if you'd like), but if I weren't using Remix, I would 100% be looking into using tRPC for this capability.

Type guards/assertion functions is also the approach you’d want to use to handle 

 for your forms. Personally, I’m really enjoying using 

, but the idea is the same: Code that actually checks the types at runtime and gives you type safety around the boundaries of your app.

I talked about two tools that generate types for your Remix conventional routes, those are a form of type generation to help solve the problem of end-to-end type safety. Another popular example of this workaround is 

 (my favorite ORM). Many GraphQL tools do this as well. The idea is to allow you to define a schema and Prisma ensures that your database tables match that schema. Then it also generates TypeScript type definitions that match the schema as well. Effectively keeping the types and database in sync. For example:

Any time you make a change to your schema and create a migration script, prisma will update the types that it has in your 

 directory so when you interact with the prisma ORM, the types match the current schema. Here’s a real-world example from the 

And this is what’s generated from that:

This gives a fantastic developer experience and serves as the starting point to my types that flow through my application on the backend.

The primary danger here is if the database schema and the data in the database somehow get out of sync. But I’ve yet to experience that with Prisma and I expect that to be quite rare, so I feel pretty confident in not adding assertion functions around my database interactions. However, if you’re not able to use a tool like Prisma or if you’re not the team responsible for the database schema, I suggest that you find a way to generate types for your database based on the schema because it’s just fantastic. Otherwise you may want to add assertion functions to your database query results.

Keep in mind we’re not just doing this to make TypeScript happy. Even if we didn’t have TypeScript, it would be a good idea to have some level of confidence that data going between a boundary in your application is what you expect it is. Remember:

Helping TypeScript with Conventions/Config

One of the more challenging boundaries is the network boundary. Verifying what the server is sending your UI is tricky. 

 doesn’t have generic support, and even if it did you would be lying to yourself:

Allow me to let you in on a dirty little secret about generics… Almost any function that effectively does this is probably a bad idea:

 (a type cast), you should think: “That’s lying to the TypeScript compiler” which sometimes is what’s required to get the job done, but I don’t recommend doing this like the 

 function above. You’ve got two choices:

In both cases you’re lying to TypeScript (and yourself), but in the first case you don’t know it! If you’re going to lie to yourself, you should at least know that you’re doing it.

So what do we do if we don’t want to lie to ourselves? Well, you could establish a strong convention for your fetching and then inform TypeScript of that convention. That’s what’s done with Remix. Here’s a quick example of that:

 function is a generic which accepts a Remix 

 function type and is able to determine all possible JSON responses (huge thank you to the creator of zod, 

 function runs on both the server and client, but getting those types across that network boundary just kind of happens thanks to the generic understanding Remix’s loader convention. Remix will ensure that the data returned from the loader will end up being returned by 

. All in one file. No API routes necessary 

If you’ve not experienced, you just gotta believe me that this is an 

 experience. Just imagine we decide we want to display the 

 field in our UI. That’s as simple as updating our 

 for the database query, and then we suddenly have that available in our UI code without changing anything else. Completely type safe! And if we decide we no longer need the 

 and we’ll get red squiggles (and type checking errors) everywhere we were using the 

 in the backend. This is because the data has to go through the network boundary and in the process everything gets serialized to a string (JSON doesn’t support Dates). The type utilities enforce this behavior which is stellar.

If you plan to display that Date, you probably should format it in the 

 before sending it over to avoid timezone weirdness when the app is hydrated on the user’s machine. That said, if you don’t like this, you can use a tool like 

 to get those data types restored in the UI.

s as well. Here’s an example of that as well:

 returns ends up being the type (serialized) that our 

 which will have type safe properties as well. Also the submitted data is safely parsed by 

 following the schema I provided, so the 

 type has all my data parsed and ready to go. There are other libraries for this, but the point is, with a few simple utilities we can get some fantastic type safety across boundaries and increase our confidence in shipping. Well, the API for the utilities is simple. Sometimes the utilities themselves are pretty darn complex 

It should be mentioned that this works throughout other Remix utilities as well. The 

 thing is just the bee’s knees. I mean, heck, watch this!

Across the network typesafety

The point I’m trying to make here is that type safety is something that’s not only valuable, but achievable across boundaries end to end. That last loader example goes all the way from the database to the UI. That data is type safe from 

 and it makes me incredibly productive as an engineer. Whatever project you’re working on, think about how you can drop a few 

 type cast lies and change it to more true type safety using some of the suggestions I’ve provided here. I think you’ll thank yourself later. It’s definitely worth the effort!

The main thing that makes end-to-end type safety difficult is simple: boundaries. The secret to fully typed web apps is typing the boundaries.

Epic Web Dev Articles by Kent C. Dodds

The Epic Stack

Full Stack Components

Fully Typed Web Apps

The Web’s Next Transition