Remix Dev Server

[ryanflorence]

Remix Dev Server

Instead of just a file watcher that writes files with remix watch, we should have a dev server receive requests, serve the asset, then proxy everything else to the real server. This should make building developer tooling better for us and our users better (live reload, HMR, faster incremental builds, forwarding build errors to a browser modal, etc.)

Background

Two important concepts drove today’s Remix’s npm run dev design:

1. Development should match Production as much as possible. This leads to fewer surprises in production and also helps developers see the effect of code changes to the network tab. Many of today’s tools have wildly different looking network tabs in production vs. development.
2. Apps own their server. In order to deploy anywhere, it’s important that Remix remain server agnostic, and remain “just a web fetch request handler” on the server.

How it works today: two processes

Two Processes need to run for remix development today: remix watch and a command to run a server like node server.js or wrangler dev etc.

• remix watch: This isn’t actually a server, it’s a file watcher. It reads remix.config.js to know where to write the server and client build artifacts. It does not receive requests, it just spits out files where the web server is reading from.
• actual server: The real server, like node server.js, requires the server build that remix watch created (it’s just a module in the end) and uses it as the request handler. When the page is viewed in the browser, the assets remix watch created are requested from the actual server, as long as it’s correctly configured to server them of course!

In other words: dev and production are identical when it comes to what happens when a request for a document or a static asset is made. The server (node server.js) serves everything. remix watchsimply created the modules for the server and client. In this way, Remix can be deployed anywhere.

The exception: remix dev + remix-serve

For developers who don’t care to run their own server, the remix-serve package creates an express app configured just enough to run a Remix app. It has an integration with the remix CLI to run both the watcher (from remix watch) and the express server in the same process.

Problems today

Requiring two processes is annoying. Many developers today are not used to owning so much of the stack (which is why we created remix-serve).

Ports and Live Reload. It’s actually surprisingly difficult to develop two Remix apps at the same time. When you have two processes you can’t simply provide a --port 3001 cli option. You may do wrangler dev --port 3000 for one app and nodemon server.js --port 3001 in another. That’s fine for the servers but the live reload web socket, that’s part of remix watchneeds to specify a port too, and that port needs to be known for both SSR (server bundles) and in the browser (client bundles). In order to get the correct web socket port for both remix watch and wrangler dev, we use an environment variable which is not only cumbersome but also super weird: it’s read at runtime for the server render (actual environment variable) but bundled as a static value into the client modules (not actually an environment variable!).

Perhaps in the live reload case, we could figure out a better way to do it (like a cli option that gets bundled directly into both client/server bundles) but it illustrates the point well that having two processes in development adds some complexity. In fact, there have been a bunch of breakages around live reload in various commits because folks both outside and inside of Remix because they didn’t understand all the moving parts.

Proposal

I’m proposing we change the way Remix works in development by introducing a development server. Instead of requests always coming to the real server in development (node server.js), requests come to a Remix development server.

• This development server handles the client assets dynamically
• Other requests are proxied to the real server

API

• remix.config.js has a new dev field that indicates how to spawn your development server

  { "dev": "nodemon server.js" }

• remix dev boots a development server that also spawns the real server

When a requests comes in, the dev server matches it against the remix.config for assets, if it matches, it serves the file (with some bundling). If it doesn’t match, it proxies the request to the real server.

Expected benefits

Having a persistent dev server should make all of the “DX” things we want to do easier to deal with because we get to receive the requests first.

• Live reload ports should be easier (could just find a port and tell the child process and the client bundles what it is)
• We have a persistent dev server so we can stop doing the require cache purge in remix-serve and the express adapter, just restart the child process when the build changes
  • This is very important for live reload and I’d expect HMR, so we don’t tell the browser the update is ready until it actually is. Many remix apps with concurrently and pm2-dev have race conditions where the browser reloaded when files changed but the builds aren't done!
• In the future we can bundle only the assets that are needed for the request. Though esbuild is already very fast for bundling the entire application, we could keep it fast forever by only bundling the code path being rendered (client and server).
• we’ll stop barfing a billion files into the build and public/build directories

The core benefit is that we are in control of when to notify the browser of anything with a persistent server that owns both processes. By spawning a child process for the real server, we also don’t lose the “development and production are nearly identical” either. All assets are bundled the same, served from the same URLs controlled by remix.config.

[benjaminsehl]

Love this effort. One clarifying question:

Development should match Production as much as possible. This leads to fewer surprises in production and also helps developers see the effect of code changes to the network tab. Many of today’s tools have wildly different looking network tabs in production vs. development.

This is such a huge win with Remix today. I believe the answer is no, but would the above proposal compromise that?

[ryanflorence]

The network tab should look identical to today.

Before:

1. remix watch barfs assets into wherever remix.config says
2. request comes into the actual server for an asset
3. the asset is served by the actual server (like express.static or some yaml config in lambda)

After:

1. remix dev fires up a dev server and spawns the real server as a child process
2. a request comes to the remix dev server
3. the dev server matches the request against the remix.config spot for building assets and sends the asset (from memory, probably) at the same URL

So the real server never actually serves the static assets, but the URLs are the same.

In other words, in production the files are on disk and served by the actual server, in development they're served by the dev server from memory.

[fergusmeiklejohn]

The trick with stateful HMR is we want to know when to preserve state and when to refetch. Server changes I imagine we'd want to default to do a slow refetch, client side changes are a grey area in most apps though in Remix apps maybe a lot less so, CSS changes should always be almost instant, as they are in the browser dev tools. Is it possible to know what kind of code we've changed and refresh accordingly?

[pcattori]

remix.config.js has a new dev field that indicates how to spawn your development server

{ "dev": "nodemon server.js" }

Is server.js the user-owned real server or the dev server? I would have expected:

remix.config.js has a new dev field that indicates how to spawn your real server

[pcattori]

Would the the original route be proxied to the real server?

For example, if /products/$productId is visited in the browser and this is proxied to the real server which returns the HTML document, then that document could be referencing code-split chunks. But the dev server is not guaranteed to produce the same number of chunks (let alone same chunk names or fingerprint). We could simply return empty responses for chunks and return the whole route JS as one file to get around this.

But curious how you envision this working @ryanflorence
Having a sketched out example of a route URL coming in and being handled by the dev server and real server would be helpful.

Nevermind! I assumed "we’ll stop barfing a billion files into the build and public/build directories" implied doing this in-memory, but that's not the case.