Optional synchronous loaders

[asacarter]

Coming from mostly server side dev background, I've been using/ learning Remix for the last few weeks. I've been reluctant to start using NodeJS before I discovered Remix. It's very impressive apart from one thing - Al loaders are loaded synchronously. I know there is talk of middleware and context to share data between loaders but there should also be a mechanism to allow a loader to be loaded synchronously when required and inherit the loader data from a parent loader.

Context that requires sessions using cookies won't work in a iframe where cookies are blocked.

Authentication is a typical use case for a sync loader. When Remix has so many features to avoid code duplication on the client, why is authentication code required to be duplicated in every loader on the server? I get that the parallel loading of routes is a feature of Remix but I don't think it should be enforced. The code duplication just feels wrong.

My proposal is that it should be an optional feature of the router. It could be implemented by a prefix in the filename to indicate that child routes are loaded synchronously and child routes inherit the parent loader data (or via a method).

In this scenario, how much of a performance deficit is there going to be vs code repetition when the child routes depend on the authentication data anyway?

For example:

_!app.jsx                 // Authentication is performed in a pathless route - ! could indicate children are loaded in sync
_app._index.jsx
_app.product.jsx            
_app.product.$id.jsx    }  All other routes are loaded async
_app.product.add.jsx   }

[reconbot]

Do you mean parallel vs in series?

[asacarter]

Yes, in series so that data from parent loaders can be inherited in child routes.

[sergiodxa]

In this scenario, how much of a performance deficit is there going to be vs code repetition when the child routes depend on the authentication data anyway?

Let's say you have a URL like /users/123, this URL could be matching two or three routes, let's imagine it matches the routes root, routes/users and routes/users.$userId.

Now, let's say each route has a loader, the loader of root takes 100ms to run because it needs to get the current user and some global data, the loader of routes/users takes 300ms because it loads more data (the list of users), and the loader of routes/users.$userId takes 400ms because it needs to get all the data of the user and many other related tables and maybe fetch some external API to aggregate the data.

In the Remix model where every loader runs in parallel, the whole request takes 400ms, so it's basically equal to the slowest route loader matching the URL, basically it does this:

let [rootData, usersData, userData] = await Promise.all([
  rootLoader({ request, params, context }),
  usersLoader({ request, params, context }),
  userLoader({ request, params, context }),
]);

If Remix run the loaders sequentially it will not take 800ms, the sum of every loader, because it will be doing this:

let rootData = await rootLoader({ request, params, context });
let usersData = await usersLoader({ request, params, context });
let userData = await userLoader({ request, params, context });

You can see how by running them sequentially, your app is now twice as slow as before.

The middleware RFC #7642 aims to give you a pre-loaders step that you can use to run some blocking and ideally fast code that you need before loaders, so if you now add an authentication middleware to the root route, the result would be similar to this:

let middlewareResult = await authenticationMiddleware({ request, params, context });
let [rootData, usersData, userData] = await Promise.all([
  rootLoader({ request, params, context, middlewareResult }),
  usersLoader({ request, params, context, middlewareResult }),
  userLoader({ request, params, context, middlewareResult }),
]);

If we suppose the authentication middleware takes 50ms, it means our whole request will get a response in 450ms which would be equal to the slowest route loader (400ms) plus the middleware (50ms).

And since you're probably already doing what the middleware does in each route, it's more likely that the 400ms would be reduced to 350ms because it doesn't need to do the auth check anymore, so in reality the whole response would be sent still in 400ms, with the difference that the actual times are going to be:

• middleware: 50ms
• root: 50ms (down from 100ms)
• routes/users: 250ms (down from 300ms)
• routes/users.$userId: 350ms (down from 400ms)

---

So what to do with this meanwhile?

The code duplication just feels wrong

You can get a similar behavior by moving code to your HTTP server, once nice thing of Remix is that Remix it's not your server, Remix is a request handler in an HTTP server, the default and built-in one uses Express and it's hidden from you, but you can use Express yourself, even node:http, Hono, Cloudflare, etc.

By moving the auth code to your HTTP server you can leverage those servers middleware features, or just in general run code before your Remix app runs, this way, you will be able to do the repeated code once (in the HTTP server middleware) and use getLoadContext to pass the result in the context object your loaders and actions receive in their arguments.

[MRDNZ]

I've created a proposal where minimal changes are required and we can still follow/use all built in Remix standards/functionalities. The usages is straight forward and the implementation shouldn't have any breaking changes to the api #9207