x-remix-id header

[kentcdodds]

So we can associate all transition requests together due to the parallel nature of multiple requests and cache things good...

Sorry, my brain isn't working well. Here's the conversation: https://discord.com/channels/770287896669978684/771068344320786452/870486885435310090

[barnski]

I know it is a detail but the X- prefix has been deprecated here: https://datatracker.ietf.org/doc/html/rfc6648

Maybe it would be better to follow their suggestions?

[kentcdodds]

It's still a very strong convention that a lot of libraries follow 🤷‍♂️ I don't really care either way.

[barnski]

That's true, still a lot of X-headers everywhere. I probably wrote it because I recently discovered it when trying to convince someone that we should create an x-something header in our system. 🤦

But maybe as Remix and MDN docs are best friends, the authors of Remix would want to stick to the recommendations 😄

[kentcdodds]

Personally I like the prefix despite the recommendation because it communicates that the header is custom and not standard

[kiliman]

I've actually implemented a POC. You can check it out here:

https://remix-playground.herokuapp.com/
https://github.com/kiliman/remix-playground/tree/main/patches

[ryanflorence]

Yeah this is a good feature.

The whole point is for a server to be able to associate the multiple, parallel requests Remix sends with a single, client side navigation. Primary use case is being able to share an inflight query between them.

For example, if you go from "/inbox" to "/invoices/123", three loaders will be called as fetch from the browser, all as separate requests:

1. root.js
2. invoices.js
3. $invoice.js

Remix will send off three fetch requests and each one of them may hit the database to check the user's permissions:

1. root.js: are they a part of this company?
2. invoices.js: can they see the company's invoices?
3. $invoice.js: what are their permissions on this invoice?

All of this information can be retrieved with a single query like SELECT * FROM permissions WHERE userId = ${userId} and orgId = ${orgId}.

Instead of all three loaders hitting the database with the same query, this header would allow servers to share the query with a simple inflight cache keyed by the x-remix-nav-id header.

// app/models/user.js
export let inflightCache = new Map();

export function getPermissions(request, userId) {
  let navId = request.headers.get("X-Remix-Nav-Id");
  let inflight = inflightCache.get(navId);
  if (inflight) {
    return inflight;
  }
  let promise = db.getUserPermissions(userId);
  inflightCache.set(navId, promise);
  return promise.finally(() => inflightCache.delete(navId))
}

// root.js, invoices.js, $invoice.js
// can now all just call this function and a single db call will be shared
// for each fetch request coming in for the same nav id
import { getPermissions } from "../models/user"

export async function loader({ request } ) {
  let user = await getUserSession(request);
  return await getPermissions(request, user.id)
}

Notes

• This only works for servers that will handle all three requests on the same process, some serverless architectures might send each request off to some other machine. It won't break, but it won't share inflight db reads, not a big deal, just something for people to be aware of
• Should probably use the web crypto API to get a unique ID, I'd hate for Remix to be responsible for a data security issue where a server thinks it can give a student the permissions of a teacher and change their grades (not that I've ever seen that happen 🤫). If we used something naive like an incrementing counter or a Date.now() then it'd be really easy for two users to send the same id. This would probably be enough: crypto.getRandomValues(new Uint32Array(1))[0].toString(). The IDs are so temporary it seems impossible to hit a collision (we'd need a collision while two people are navigating at the same time). If we wanted to, we could generate RFC 4122 compliant UUIDs with a bit more code.
• Another use case is being able to measure how long a navigation takes for the server for performance metrics.

[sergiodxa]

I think you can use crypto.getRandomValues for now until this https://github.com/WICG/uuid is ready, from the dev using Remix perspective we know that header comes and is supposed to be unique, we should rely on it being uuid or number or date or anything

[kiliman]

I noticed that you're using promise.finally() to cleanup the cache. Wouldn't that result in possibly deleting the cached item before some other loader could get the value, thereby negating the caching benefit?

That's why I added the loader count in my implementation, so I could keep track of the requests in flight and then cleanup the cache once all loaders have finished.

Anyway, the more I've played with it, the more I believe that client-side transitions should be sent as a single request. This makes the server-side processing consistent regardless of the type of transition. It also enables caching for providers that may process different loader requests on separate hosts. It just makes it simpler to reason about:

1 Request => 1+ loaders in parallel. 

I'm not sure if that's too big a change at this point in time. I just feel that it might confuse people in the long run.