realm vs async context

[ronag]

The fetch spec mentions "realm" and "relevant realm" a lot. I assume this is something similar to async context in NodeJS? Should we try to translate the API and implement accordingly?

[ronag]

@mcollina wdyt?

[mcollina]

Realm is defined as https://html.spec.whatwg.org/multipage/webappapis.html#realms-and-their-counterparts. This is not related to async context.

Unfortunately it's not possible to implement that or other things related to it. In the browser a realm is associated with a unique user/human being, i.e. it's the Window object. It's the reason why we can use this as the basics for CORS or http auth. In a generic Node.js application we are exposing an API that is being used by more than one concurrent user, therefore we cannot implement this part of the spec.

This is the reason why I always said that we will never be able to be 100% compliant to the fetch() standard.

---

If I understand correctly your point about Async Context, I think we could implement in a non-standard way is an API such as:

import { fetch, FetchRealm } from 'undici'

const realm = new FetchRealm(...) // this is end user specific

await realm.run(async function () {
  await fetch(...) // will automatically get the details from the Realm
})

Essentially creating a user-specific object where we can store user-specific data (auth, cookies, potentially CORS), etc..

[ronag]

If I understand correctly your point about Async Context, I think we could implement in a non-standard way is an API such as:

That's exactly what I was thinking! We can map a lot of the browser concepts into that e.g. current settings object, environment settings etc...

[mcollina]

My only worry is if this would be useful to our Node.js users. Why would somebody need that?

[ronag]

My only worry is if this would be useful to our Node.js users. Why would somebody need that?

Heh, good question. Let me give it some more thought.