Remix runtimes, adapters, templates and deployment

Adventures in amateur web development…

❗ This is not a tutorial ❗

Reading https://remix.run/docs/en/main/discussion/runtimes

Deploying a Remix application has 4 layers:

  • a JavaScript runtime like Node.js
  • a JavaScript web server like Express.js
  • a server adapter like @remix-run/express
  • A web host or platform

??? I guess what’s throwing me off is the “JavaScript runtime”:

“Runtime” just means “execution environment”? I’ll go with that for now. I guess the issue is that each runtime (node, deno, etc) has varying support for the Web APIs that Remix uses. Remix runtime packages are used to fill in any missing features.

Adapters

Remix is not an HTTP server. It is a handler that exists inside of an HTTP server. Adapters are used to allow Remix to run inside an HTTP server.

Edit: I was following the docs in order, but the runtime, server, adapter section assumes some prior knowledge. Trying to clarify how the parts fit together with ChatGPT:

Me:

In the context of a Remix application that is having requests forwarded to it by Nginx (with a reverse proxy setup on Nginx) is Nginx the HTTP server? What I’m wondering is if there’s some other node process that’s running that could be considered to be an HTTP server.

ChatGPT:

In the context you’ve described, where Nginx is set up as a reverse proxy to forward requests to a Remix application, both Nginx and the Node process running the Remix app can be considered HTTP servers, but they serve different roles in your architecture:

  • Nginx as the HTTP Server: Nginx is the front-facing HTTP server that directly interacts with clients (browsers, API consumers, etc.). It accepts incoming HTTP requests and forwards them to the backend Remix application based on the reverse proxy configuration. Nginx can handle static content, SSL/TLS termination, compression, caching, and load balancing. In this setup, Nginx is definitely acting as an HTTP server, dealing with HTTP requests and responses.
  • Node Process/Remix Application as the HTTP Server: The Node process running the Remix application also acts as an HTTP server but in a slightly different context. It listens for requests forwarded by Nginx, processes them (e.g., dynamic content generation, business logic, database interactions), and sends back responses to Nginx, which then relays these responses to the client. This Node process typically uses an HTTP server library (like the built-in http module in Node.js, Express.js, or Koa) to handle the HTTP aspects of the requests and responses.

So, in your setup, you have two HTTP servers working together:

  1. Nginx acts as the public-facing HTTP server, handling initial client requests, performing reverse proxy functions, and applying optimizations or security measures.
  2. The Node process (Remix application) acts as an internal HTTP server that handles application-specific logic and generates the content or responses to be sent back to the client through Nginx.

This architecture allows you to leverage the strengths of both Nginx (e.g., performance, security, static content serving) and your Node-based Remix application (e.g., dynamic content, application logic) effectively.

So the “adapter” part is between Remix and the Node process.

Templates and Deployment

Templates are just starting points for apps: https://remix.run/docs/en/main/guides/templates.

I’ll deal with deployment when I’ve got something to deploy.