Providing a mechanism config for remix-run/serve

[neverstew]

Context

Here's a short twitter thread between myself and @kentcdodds that sparked this discussion.

Problem

I've just started a new project with the Indie Stack and I've deployed it straight to a single region on fly.io to take advantage of the excellent response times. I have a static asset that I want to be cached for users pretty much all the time, something like a logo. To accomplish this right now, I'd need to set up some config outside of my application, beginning a journey away from the simplicity of the Indie Stack that I opted for in the first place.

Proposal

remix.config.js accepts options for remix-run/serve that can be passed along to the express server that it starts. These would be a simple passthrough at the related points in the server setup, with the key of the option relating pretty much 1-1 to a line in the server startup.

Example

// remix.conf.js
{
  ...,
  serverOptions: {
    static: { maxAge: "1y" }
  },
  ...,
}

The static object maps directly to the static middleware initialisation on this line and takes the config provided or falls back to the current default.

This could potentially open the door to allowing other config to be manipulated with the same mechanism.

I'm not wedded to this mechanism at all and I can see that there might have to be an intermediary step required to take these options and persist them at run time outside the remix.config.js file (which I believe is not in the build artifacts). On first glance, from a DX perspective it seems like the place that this stuff should live.

[kiliman]

Remix App Server is basically a batteries-included no-config option for running Remix apps. If you want more configuration, the solution is to use the Express adapter. I've written a script that will let you "eject" from RAS to Express. It uses the latest files from the Express template. Then you can edit server.js as much as you'd like.

https://github.com/kiliman/rmx-cli#eject-ras

[kentcdodds]

Yeah, the more I think about this, the more I think that what we have for cache headers within remix server is pretty sufficient for most use cases, and ejecting to a regular express server is a fine answer for any further customization 👍

[neverstew]

That sounds much easier to me as well. An exit strategy for the Indie Stack that involves this would be something I'd love the docs to signpost.

[jamesarosen]

eject-ras is an OK starting point, but has two important drawbacks:

1. It doesn't support TypeScript, which Remix broadly does. This could be fixed with ts-node or by running tsc --watch on server.ts.
2. The applications are completely disconnected from @remix-run/serve, so they won't benefit from updates to the library. Application maintainers will have to watch the changelog carefully and port any necessary changes.

For this reason, I believe @kiliman's suggestion to allow overriding the Express server (but not the cli process) is the most maintainable solution.

[joekrill]

What about adding an environment variable for overriding the maxAge for public assets? So setting STATIC_ASSETS_MAX_AGE would just override the default value? There's certainly some precedence since PORT, HOST, and NODE_ENV act to configure remix-serve in a similar way. Much simpler than a full-blown config file. Is that something you'd be open to?

[kentcdodds]

I think if you need to customize the server it's simpler and easier (for you and us) to just "eject" to your own express server. Michael Carter's even put together a CLI to help with this process: https://github.com/kiliman/rmx-cli#-eject-ras

[kiliman]

I think instead of opening up RAS to configuration, perhaps just have the ability to specify the server file. By default, it would use its own internal Express server. But if you provide a server file, it will import that instead. This way, developers get the DX of simply doing remix dev without having to spin up a separate Express server.

[kentcdodds]

That sounds like a good idea to me 👍

[jamesarosen]

Agreed. I don't want to manage the cli portion, just the Express app.

There are lots of things that are best addressed at the HTTP level via middleware. (e.g. HTTP caching, redirects, HSTS, header manipulation). I don't want to "eject" to a full separate server via config.server because that disables remix dev and the great developer experience that brings with it.

[kiliman]

I've created a patch to allow you to specify the server file to use with Remix App Server. It even supports TS files. You just need to export a function named createApp. I want to add an eject command that will generate the server file for you. The cool thing about this is you now get to customize the server all you want but still get the DX benefit of using npm run dev. No need to spawn a separate express server.

You can also export optional createServer and createSocketServer functions in case you need to customize it as well, like supporting HTTPS.

BTW: I had to create a new config option. The server option actually bundles the server code with your app, which is not what I wanted. I plan to submit a PR soon.

//server.ts
import { createRequestHandler } from "@remix-run/express";
import compression from "compression";
import express, { type Express } from "express";
import fs from "fs";
import https from "https";
import morgan from "morgan";
import WebSocket from "ws";

export function createApp(
  buildPath: string,
  mode = "production",
  publicPath = "/build/",
  assetsBuildDirectory = "public/build/"
) {
  let app = express();

  app.disable("x-powered-by");
  app.use(function (req, res, next) {
    res.setHeader("X-Powered-By", "TS Remix App Server");
    next();
  });
  app.use(compression());

  app.use(
    publicPath,
    express.static(assetsBuildDirectory, { immutable: true, maxAge: "1y" })
  );

  app.use(express.static("public", { maxAge: "1h" }));

  app.use(morgan("tiny"));
  app.all(
    "*",
    mode === "production"
      ? createRequestHandler({ build: require(buildPath), mode })
      : (req, res, next) => {
          delete require.cache[buildPath];
          let build = require(buildPath);
          return createRequestHandler({ build, mode })(req, res, next);
        }
  );

  return app;
}
export function createServer(app: Express, port: number) {
  const server = https
    .createServer(
      // Provide the private and public key to the server by reading each
      // file's content with the readFileSync() method.
      {
        key: fs.readFileSync("server.key"),
        cert: fs.readFileSync("server.crt"),
      },
      app
    )
    .listen(port, () => {
      console.log(`server is running at https://localhost:${port}`);
    });
  return server;
}
export function createSocketServer(config: { devServerPort: number }) {
  const server = https.createServer(
    // Provide the private and public key to the server by reading each
    // file's content with the readFileSync() method.
    {
      key: fs.readFileSync("server.key"),
      cert: fs.readFileSync("server.crt"),
    }
  );
  const socket = new WebSocket.Server({ server });

  server.listen(config.devServerPort, () => {
    console.log(
      `socket server is running at https://localhost:${config.devServerPort}`
    );
  });
  return socket;
}

// remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  ignoredRouteFiles: ["**/.*"],
  serverEntryFile: "./server.ts",
  // appDirectory: "app",
  // assetsBuildDirectory: "public/build",
  // serverBuildPath: "build/index.js",
  // publicPath: "/build/",
};

[jamesarosen]

The server option actually bundles the server code with your app, which is not what I wanted

Can you elaborate on this?

[kiliman]

Yes, if you use server: './build/index.js' that just tells Remix to bundle the entire app code + node_modules into a single file (roughly 3+MB)

The change I was referring to is in PR #4123 which allows you to create a file that creates the Express server to be used by Remix App Server (instead of the non-configurable version it currently uses).

[jamesarosen]

Got it. The nice thing about the server config is that remix watch live-compiles TypeScript for you. But your PR is the best of both worlds!

[kiliman]

Yeah, I love that remix dev runs both the web server and the Remix watcher. It simplifies the config vs what you have to manually manage with the Express adapter.

[kiliman]

Plus I extended it so you can configure the web socket server as well, especially if you need to support SSL.