[Feature]: middleware before Remix processes request

[a-type]

What is the new or updated feature that you are suggesting?

Enjoying Remix so far, but there's one key feature I'd like to see for multi-tenant apps: the ability to intercept and modify an incoming request before handing it off to the core Remix runtime which is agnostic of the deployed platform.

The multi-tenant use case is to enable wildcard subdomains which route to a particular nested route structure within the app. For example, foo.myapp.com/bar could be rewritten and rendered as myapp.com/_sites/foo/bar, utilizing the routing structure within /routes/_sites to render the foo tenant's 'website' using the same codebase as the core app.

This behavior can't be achieved within entry.server.ts, since by the point that is called, Remix has already done up-front route matching on the original URL. Any userland code we could write to achieve this rewriting would have to be supplied to the server runtime directly.

Currently, the only working alternative which enables URL rewrite-based multi-tenancy is to modify the platform-specific deployment entrypoint (i.e. /api/index.js for Vercel, etc) to rewrite the URL before Remix gets it. But this only works in deployed environments (not locally), and would have to be rewritten for different deployment targets if you switch.

CC: #1475

Why should this feature be included?

• Multi-tenancy is very difficult to get right with Remix without it. You either have to include ballooning special-case logic within the routes themselves ("am I on a subdomain tenant site or the main site?" on every route) or customize your deployed platform code to modify the request beforehand and accept not being able to test subdomains on localhost.
• The ... obvious competing framework has explicit support for subdomain mult-tenancy utilizing a special 'middleware' concept, roughly similar to what I've requested here.
• Subdomain multi-tenancy is increasingly common and a desirable feature for all sorts of sectors, whether it's a B2B dashboard, communication apps for teams, website builders, nocode tools, social network apps, or anything where a user would want to stake a claim on a section of your app.
• A request middleware could also prove more useful than just for multi-tenancy or URL rewriting at all. Perhaps you want to add or remove other parts of the request, like headers or cookies.

[esamattis]

Another important use case for middleware is database connection pooling. We need to be able to ensure the database connections are released back to the pool at end end of the request even if an error is thrown in a loader/action.

So for now we need to use this useDB(async db => {}) wrapper to ensure we don't accidentally run out of PostgreSQL connections. Where the useDB() is a try-finally wrapper like this:

function useDB(fn) {
    const db = POOL.get(); 
    try {
        await fn(db);
    } finally {
        db.release();
    }
}

This is OKish but it makes loaders and actions needlessly nested:

export const loader: LoaderFunction = async () => {
    await useDB(async (db) => {
        await db.query(...)
    });
};

It would be awesome to have a central place to extend the loader/action context so we could implement something like this:

export const loader: LoaderFunction = async ({ db }) => {
    await db.query(...)
};

[a-type]

@esamattis good use case. It seems like entry.server.ts handleDataRoute could almost do what you need, but it only exposes modifying a response, not doing pre-request setup. There's still the problem of instantiating the pool and putting it into context.

This would be at least feasible to improvise in userland in the meantime, with a custom loader/action higher-order wrapper -

function dbLoader(loaderImpl: (event: Parameters<LoaderFunction>[0], db: DbPool) => ReturnType<LoaderFunction>): LoaderFunction {
  const loader: LoaderFunction = (event) => {
    return useDB((db) => {
      return loaderImpl(event, db);
    });
  }
  return loader;
}

// ...

export const loader = dbLoader(async ({ request }, db) => {
  await db.query(...);
});

[esamattis]

I think user land middleware should be now possible with getLoadContext() in the Express adapter which gets access to the Node.js request and response just by listening on the end event of the response object. But that's going to be Express/node.js specific.

It seems like entry.server.ts handleDataRoute could almost do what you need, but it only exposes modifying a response, not doing pre-request setup

Is it executed on loaders and actions too? Seems like it is always doing react rending 🤔

a custom loader/action higher-order wrapper

This is actually pretty good solution but I wonder whether does it get properly removed from the browser builds.

Thanks for the ideas! I'll be investigating/testing these more on next week!

[esamattis]

I wonder whether does it get properly removed from the browser builds.

Did some testing and it does not get removed from the browser bundles under public/build but it seems Remix does not remove remove even the plain loader and action code like Next.js does for getServerSideProps. So I guess this is a separate issue (or feature?).

UPDATE: Sorry, plain function elimination / pruning works. I just had some side effects in the module while testing. But that explains why the higher order function does not work: It is a side-effect.

[a-type]

Hm, that's troubling (probably worth a second issue). I'd hope that we could introduce composition functions over loaders and actions in userland without any problems.

[miraage]

I was looking for a graceful way to handle subdomain multi-tenant logic. Out of the box support would be much appreciated.

Same goes for language/region/city detection. I can technically use a loader in root.tsx, but I think this logic is application-wide and doesn't necessarily belong to anything related to react.

[styxlab]

There is no need for a middleware concept for multi-tenancy apps (see my comment on #1337).

[a-type]

That will only work if route paths match exactly between subdomain situations and non-subdomain - i.e. tenant.my.app/page is the same page as my.app/page but with tenant-scoped data.

But if tenant.my.app/page is equivalent to my.app/~tenants/[tenantName]/page or some other structure, the solution is not as simple as just knowing the hostname - you also have to render an entirely different experience for route structures based on that host.

This ballooning complexity problem is what I was referring to in the original issue text. The only simple solution I can see is to rewrite tenant.my.app to my.app/~tenants/[tenantName] before Remix does anything at all. Then multi-tenancy is a 1-line feature tucked away into my middleware and a straightforward nested route quirk, not a sprawling concern spread across every route and loader in the codebase.

[styxlab]

@a-type Yes, I agree - in my use case, the routing structure does not change based on different tenants. The ability to perform rewrites in middleware would open more complex use cases and I would also like to see it. If you are on Cloudflare, you could dedicate a worker just for doing the rewrites. So there are workarounds, although I would prefer a native remix solution.

[kiliman]

One of the reasons why Remix doesn't support rewriting URLs is that the URL that it's processing must match the URL that is in the address bar. This is because React Router (which Remix is built on) does client-side routing so the server URL must match the client URL.

They would have to include URL rewriting in React Router itself.

[styxlab]

Maybe I don't understand the depth of the issue, but wouldn't it be possible to have a middleware/proxy before entering React router?

incoming request -> middleware/proxy -> remix

All the rewrites would be done in the middleware layer.

[a-type]

The client-side routing definitely complicates things! Seems like the middleware may have to live in RR itself. However, that also means that even solutions like rewriting the incoming HTTP request in your lambda layer won't work, right? It would seem

Remix doesn't have any solution for the kind of use case you see in NextJS' Multi-Tenant demo using their middleware concepts. I'm not sure how NextJS middleware interacts with their client-side routing, but they've specifically showcased this kind of thing which at least validates that Vercel sees the need for this use case enough to commit effort to documenting it.

[dcramer]

Just to chime in here, this is also something that would be an appropriate entry point for functionality like Sentry to inject itself on the server. I think the pattern of having something like middleware.server.tsx and middleware.client.tsx could function here as its fairly easy know whats going on at that rate.

Since folks are contrasting to Next.js, I will say that their approach to middleware is good in some situations, but still limiting in others. For example, if you use Google's Identity-Aware Proxy it passes a signed JWT to every request which contains the authentication information. In an ideal world an app (a Remix app) could parse this and bundle that information up in its hydration phase (middleware?). It could then retain that state in memory to understand if/who the authenticated session is. AFAIK in Next.js the only solution here is to utilize cookies to pass that information. There may be other approaches but it'd certainly be convulated.

Similarly in Sentry we'd want to inject something as a middleware that ideally could access things like routing information, HTTP headers, etc. allowing us to enrich data streams (both for error reporting and tracing). That enrichment behavior would be fairly distinct on the server, but would still be desirable on the client. So while it's certainly possible you could come up with an API that lets you write-once-run-everywhere middleware, I personally would be fine with having an implementation for each runtime.

[martinmckenna]

+1 on this. I'm writing an app right now that's using an external API that uses bearer auth and I'd like to add some server middleware to get my auth token from an HTTP-only and add it to the Authentication headers.

Is my solution just to use an Express server and write middleware there?

[CanRau]

I to think it would be pretty powerful if Remix could provide a way without requiring a custom express server (or node at all)

Would like to do redirects before Remix and inject my db instance like getLoadContext but the custom express server way seems unnecessarily complicated

Or maybe I just haven't properly figured out how to bundle the server.ts with Remix 🤔😅

[parisholley]

For anyone interested, I started a patch that I have been using locally to solve for some of the "global, once per request" logic as well as global server-side error handling (eg: pushing to sentry)

entry.server.tsx

export function handleError(request: Request, error: Error, context: any) {
  const logger = container.get<Logger>(Binding.LOGGER);

  logger.error(error);
}

export async function buildLoadContext(request: Request): Promise<RequestContext> {
  // create container (inversify) on first request, re-use container on subsequent requests
  await buildContainer();

  // create a unique ORM entity manager for each request
  const factory = await container.getAsync(MikroManagerFactory);

  return {
    log: container.get(Binding.LOGGER),
    mikro: factory.create(),
    container, // allow routes to pull services from container
  };
}

In theory, you could use the same load context function to add conditional guards (eg: if path = x or params = y), but a cleaner solution would be needed to define at the path/folder route level.

patch:

diff --git a/dist/server.js b/dist/server.js
index eb21a54aeafb4265d6fc9b31b576245cc1b44538..ddceaf275fa8c0de5b04aece0bdd43649ce3040d 100644
--- a/dist/server.js
+++ b/dist/server.js
@@ -23,17 +23,25 @@ var responses = require('./responses.js');
 var serverHandoff = require('./serverHandoff.js');
 
 const createRequestHandler = (build, mode$1) => {
+  if (build.entry.module.handleError === undefined) {
+      build.entry.module.handleError = (() => {})
+  }
   let routes$1 = routes.createRoutes(build.routes);
   let serverMode = mode.isServerMode(mode$1) ? mode$1 : mode.ServerMode.Production;
   return async function requestHandler(request, loadContext) {
     let url = new URL(request.url);
     let matches = routeMatching.matchServerRoutes(routes$1, url.pathname);
     let response;
+    let lc = loadContext;
 
+    if(build.entry.module.buildLoadContext){
+      lc = await build.entry.module.buildLoadContext(request);
+    }
     if (url.searchParams.has("_data")) {
       response = await handleDataRequest({
         request,
-        loadContext,
+        loadContext: lc,
+        handleError: build.entry.module.handleError,
         matches: matches,
         handleDataRequest: build.entry.module.handleDataRequest,
         serverMode
@@ -41,14 +49,16 @@ const createRequestHandler = (build, mode$1) => {
     } else if (matches && !matches[matches.length - 1].route.module.default) {
       response = await handleResourceRequest({
         request,
-        loadContext,
+        loadContext: lc,
+        handleError: build.entry.module.handleError,
         matches,
         serverMode
       });
     } else {
       response = await handleDocumentRequest({
         build,
-        loadContext,
+        loadContext: lc,
+        handleError: build.entry.module.handleError,
         matches,
         request,
         routes: routes$1,
@@ -71,6 +81,7 @@ const createRequestHandler = (build, mode$1) => {
 async function handleDataRequest({
   handleDataRequest,
   loadContext,
+  handleError,
   matches,
   request,
   serverMode
@@ -145,9 +156,7 @@ async function handleDataRequest({
 
     return response;
   } catch (error) {
-    if (serverMode !== mode.ServerMode.Test) {
-      console.error(error);
-    }
+    handleError(request, error, loadContext);
 
     if (serverMode === mode.ServerMode.Development) {
       return errorBoundaryError(error, 500);
@@ -160,6 +169,7 @@ async function handleDataRequest({
 async function handleDocumentRequest({
   build,
   loadContext,
+  handleError,
   matches,
   request,
   routes,
@@ -233,9 +243,7 @@ async function handleDocumentRequest({
       appState.trackBoundaries = false;
       appState.error = await errors.serializeError(error);
 
-      if (serverMode !== mode.ServerMode.Test) {
-        console.error(`There was an error running the action for route ${actionMatch.route.id}`);
-      }
+      handleError(request, error, loadContext);
     }
   }
 
@@ -315,9 +323,7 @@ async function handleDocumentRequest({
       appState.trackBoundaries = false;
       appState.error = await errors.serializeError(error);
 
-      if (serverMode !== mode.ServerMode.Test) {
-        console.error(`There was an error running the data loader for route ${match.route.id}`);
-      }
+      handleError(request, error, loadContext);
 
       break;
     } else if (response) {
@@ -408,9 +414,7 @@ async function handleDocumentRequest({
     try {
       return await handleDocumentRequest(request, responseStatusCode, responseHeaders, entryContext);
     } catch (error) {
-      if (serverMode !== mode.ServerMode.Test) {
-        console.error(error);
-      }
+      handleError(request, error, loadContext);
 
       let message = "Unexpected Server Error";
 
@@ -431,6 +435,7 @@ async function handleDocumentRequest({
 
 async function handleResourceRequest({
   loadContext,
+  handleError,
   matches,
   request,
   serverMode
@@ -452,9 +457,7 @@ async function handleResourceRequest({
       });
     }
   } catch (error) {
-    if (serverMode !== mode.ServerMode.Test) {
-      console.error(error);
-    }
+    handleError(request, error, loadContext);
 
     let message = "Unexpected Server Error";

[cliffordfajardo]

Unfortunately, the regular Remix App Server doesn't expose Express API directly and I don't want to patch or hack the internals to make it work

I'm currently exploring middleware right now through the following templates:

• express remix template (official from Remix team)
• fastify-remix (unofficial but created by Remix core team member) templates.

[CanRau]

I think I heard Kent saying they are working on something "better" than middleware, whatever that means.

Hope it's also helping with dependency injection getLoadContext and stuff 🤞

[cliffordfajardo]

Sounds awesome!
Are you referring to a new API thats separate from getLoadContext?

CC @kentcdodds @brophdawg11 🙏

[kentcdodds]

Yes, this will be a new API. The current idea is a new conventional export of route modules

[a-type]

Cool, a route export sounds great, since use cases like URL transformations aren't strictly server-side concerns in an SPA. Glad the Remix team has this under consideration!

[jrestall]

Middleware for me is the biggest remaining feature Remix needs so I'm excited to see the new API @kentcdodds. I want to humbly express some of my requirements so that they can be considred for the design.

Requirements

• run on client and/or server based on existing *.server.ts or *.client.ts naming conventions.
• can set promises with waitUntil that block route transitions or enable middleware tasks to be executed in parallel.
• support dependency injection by modifying data function arguments.
• prevent rendering a route or executing a loader/action based on throwing or not calling next.
• support nesting so that middleware can be defined globally in root.tsx or nested and only run if matched.

This would greatly simplify code and improve testing and security in more complex serverless applications. The UX for localization is also critical for complex apps and middleware would solve issues like #3847 #3355. Sentry integration also wouldn't require manually monkey patching the server build object sentry-remix-node.js#L51. DX would be improved and a wide range of functional and security bugs avoided from devs forgetting to add cross-cutting concerns to their loaders/actions like csrf, session commits and db connection releasing.

I could imagine middleware looking something like the below but it sounds like the new api may provide something even better.

// root.tsx or routes/**/*.tsx (handlers for all matching routes are run)
export const handlers: HandlersFunction = () => {
  return [
    httpsRedirect, // Redirect http to https
    csrf, // Generate csrf token and add to cookie/loader data. Verify on action request.
    tenant, // Identity tenant and inject to loader/action
    authentication, // Check user is authenticated
    authorization, // Check user is authorized for route and inject user into context.
    localization, // Prefetch dynamic prompts for route before render (execute in parallel with client data loader request by returning a promise from handler)
    logging, // Log request/responses and timings on server and client
    sentry, // Log errors to sentry
    session, // Commits session automatically
    database // Automatically release db connection to the pool
  ];
}

Some middleware could look like the following based on koa 2/.net core middleware. An important feature is waitUntil that blocks the navigation until the promise resolves as discussed here by @sergiodxa. It mkaes sense to me in client middleware but I don't know about on the server.

export async function authentication(ctx: ExecutionContext, next: NextFunction) {
    const user = await getUser();
    if(!user) {
        throw new Error("User not authenticated!");
    }

    // Inject user into state for data functions to use
    ctx.state.user = user;
    await next();
}

async function localization(ctx: ExecutionContext, next: NextFunction) {
    if(ctx.type == "loader"){
        // Load prompts in parallel with loader data on client
        // NOTE: Does NOT block middleware but remix will wait for promise to resolve before route transition
        ctx.waitUntil(fetchPrompts());
    }
    
    // Continue the request
    await next();
}

async function https(ctx: ExecutionContext, next: NextFunction) {
    if(shouldRedirect(ctx.request)){
        ctx.response = redirectHttps(ctx.request)
    } else {
        await next();
    }
}

async function database(ctx: ExecutionContext, next: NextFunction) {
    const db = _connectionPool.get(); 
    try {
        ctx.state.db = db;
        await next();
    } finally {
        db.release();
    }
}

Dependency Injection Support

export const loader: LoaderFunction = async ({ state }) => {
  const { user, tenant, session, db } = state;
  // ...
};

[yasoob]

Hi everyone! Any updates on this feature? I really want to create my new project on top of remix but this feature is a major requirement.

[luchsamapparat]

It landed behind a feature flag in React Router, so hopefully it will soon be available in Remix too...?

https://github.com/remix-run/react-router/blob/brophdawg11/middleware/.changeset/hip-geckos-fold.md

The last paragraph is interesting, however

⚠️ Please note that middleware is executed on a per-loader/action basis because they can alter the Response from the target loader/action. This means that if you have 3 loader's being called in parallel on a navigation or revalidation, they will each run any existing root middleware. If these duplicate middleware calls are problematic then you will need to de-dup any problematic logic manually.

That means, that there's still no one single function that is executed before/after everything else.

I also wait eagerly for some kind of global middleware, but in my use case (which is refreshing an access token) I'm not sure if this is really the solution I was waiting for as I still have to synchronize middleware for each loader to only refresh the access token once.

[Seiikatsu]

It's been some months since the last update. Are there any updated on this topic? 🙂
We love using remix but it's been a somewhat blocking topic for us. We are using keycloak for authentication and validating / refreshing the cookies if necessary.
As loaders are running in parallel, (depending on the called route) it might happen that multiple requests are executed against keycloak.

It would be awesome to just have a middleware or something which can be executed before the loaders to check user auth / permissions.

[sergiodxa]

I think middlewares are going to come to v3 (v2 is about to be released as stable, a prerelease version is already available). Meanwhile the best approach is to setup middlewares in the HTTP server, e.g. using Express or Hono.js middlewares.

[Download]

Is there a way for us to check progress?
I am researching this because I want to set a timestamp header on every request.
For me, ideally, I would love to see a solution where I can inject code on the server side that runs before the processing of the request, but also on the client side I would like to be able to intercept all calls to fetch so I can add the timestamp header. So middleware that could run on both sides would be great!

Is it currently possible to intercept all calls to fetch? I looked at fetchers but they are per route as far as I understand. And you have to be explicit about using them. It would be ideal from my perspective if there was a way for me to provide some code that would run before/after any fetch happening from anywhere in the app without having to change all routes to explicitly use it.

[SeanRoberts]

In terms of overriding calls to fetch what I do in my projects is write a function that wraps fetch and then use that everywhere. I think this is a pretty common approach especially in BFF apps where you probably want to add auth headers or whatever else to all your calls. Although this won't help you with fetchers I don't think.

For the server side I think you can do that by using a custom server.

[Download]

Yeah, wrapping fetch came to mind. But I wonder if Remix will use the wrapped version or the original. I could probably force its hand if I make sure my code wrapping fetch runs first but currently I am not sure if I can do that in entry.client.js or whether I need to do something special. Any tips from someone in the know would be great. I will just have to experiment a bit otherwise I guess.

[rossipedia]

The most reliable way would be to render some script in root.tsx fairly high up that wraps window.fetch. Since this gets SSR-ed it will execute in the browser before any Remix client-side JS runs, and Remix should end up using your wrapped window.fetch implementation instead of the original one.

[Download]

Thanks, I am going to try this 👍

[fullstackwebdev]

Hi any update on plans for middleware?