AsyncLocalStorage From middleware to server component

[KevinEonix]

Link to the code that reproduces this issue

https://github.com/KevinEonix/next-asyncLocalStorage

To Reproduce

1. start npm run dev
2. access the default page
3. message rendered is Context is undefined :(

Current vs. Expected behavior

The phrase should be test value in store is test value

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32370
  Available CPU cores: 12
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.6 // Latest available version is detected (14.2.6).
  eslint-config-next: 14.2.6
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Developer Experience, Middleware

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I tested that on an other project and have the same problem (same machine sane versions)

[samuelstroschein]

This is blocking opral/inlang-paraglide-js#245. A related issue seems to be #53466.

[samcx]

@KevinEonix I think this is confusing how Middleware operates in Next.js—it's not meant to pass information down to Server Components. Middleware and your Next.js application are not running in the same context (not running on the same thread).

• https://nextjs.org/docs/app/building-your-application/routing/middleware#use-cases

@samuelstroschein I don't think this is related to opral/inlang-paraglide-js#245, but maybe you have more context as to why asyncLocalStorage was brought up in the other thread?

The irony is that the cookie(), header(), etc. APIs even use asyncLocalStorage() under the hood but a custom one that developers can't leverage.

You actually can, you just have to use it in the right context.

For example with Route Handlers, https://nextjs.org/docs/app/building-your-application/deploying#after.

[samuelstroschein]

@samcx please just make middleware's and async local storage work as it does in every other framework.

fact is: there is no way to pass information from a middleware to server components in a sync way which will block paraglide js usage in nextjs.

fact is also: that every other metaframework middleware just works. this is, as more often than not over the past two years, a nextjs only problem.

I don't think this is related to opral/inlang-paraglide-js#245, but maybe you have more context as to why asyncLocalStorage was brought up in the other thread?

This is related because I have to implement the middleware in propriety NextJS API that is about to break because it's becoming async. My problem is solved if AsyncLocalStorage would just work (as it does in any other SSR framework).

The irony is that the cookie(), header(), etc. APIs even use asyncLocalStorage() under the hood but a custom one that developers can't leverage.

You actually can, you just have to use it in the right context.

I appreciate your response but this is a prime example of what is wrong with nextjs atm.

Passing information to the rendering tree from a middleware is required. NextJS has an internal mechanism to leverage AsyncLocalStorage, or an equivalent mechanism, to pass cookies and headers because this is such a basic requirement.

Instead of making this API available to developers, you recommend I dig deep into NextJS internals/docs to figure out how I can use Route Handlers. Sorry but no. I am not investing that time to learn NextJS specific APIs that I need to learn because APIs that just work everywhere else don't work in NextJS

[joesonw]

next.js/packages/next/src/server/request/cookies.ts

Lines 52 to 53 in f609222

	const workStore = workAsyncStorage.getStore()
	const workUnitStore = workUnitAsyncStorage.getStore()

[samuelstroschein]

Thank you very much!

I need to slightly correct myself—you can actually pass information to Server Components, via cookies() and headers(), which is just passing information via setting headers in the request and/or response.

Correct, but I need a sync API to retrieve the cookies and/or headers.

The rendering process runs in parallel. Awaiting an async function in a layout/page does not resolve before rendering of other components starts. This is a recent breaking change that NextJS 15 introduced.

Summarized:

• a sync API is needed to retrieve data from requests
• if you find/know another way to pass data from a request to a page in a sync way, please let me know

[samuelstroschein]

@samcx here is a code example of the issues with the async cookies(), headers() API opral/inlang-paraglide-js#407 (comment). PS excuse my frustration in the comments.

[samcx]

@joesonw @samuelstroschein

Ahh I should have noticed this earlier. The cookies() and headers() functions are different from using cookies and headers in Middleware.

• https://nextjs.org/docs/app/building-your-application/routing/middleware#using-cookies

• https://nextjs.org/docs/app/api-reference/functions/cookies

• https://nextjs.org/docs/app/building-your-application/routing/middleware#setting-headers

• https://nextjs.org/docs/app/api-reference/functions/headers

I guess this clarifies that we're not using asyncLocalStorage anywhere with Middleware. Regardless, I still do agree that we should have a better mechanism for passing information from Middleware on a deployed platform.

I should further clarify why Middleware was originally designed in such a way. In a separate discussion, I sort of explain why Middleware was designed with limitations → #59888 (comment). Since Next.js was designed to be deployed where paths can be served statically, or SSR'd (or both with PPR), I think that meant Middleware had to exist as a separate compute layer (not on the same thread, meaning asyncLocalStorage isn't possible). I think there are definitely benefits to serving a web application like this, versus an web framework that relies on a single server to serve paths—in these cases, I can see Middleware being able to execute asyncLocalStorage.

a sync API is needed to retrieve data from requests
if you find/know another way to pass data from a request to a page in a sync way, please let me know

Taking a look at the shared issue to see how we can help resolve the breaking 15 changes here 👀

[samuelstroschein]

I think there are definitely benefits to serving a web application like this, versus an web framework that relies on a single server to serve paths—in these cases, I can see Middleware being able to execute asyncLocalStorage.

If the NextJS middleware is cross request safe in any environment, asyncLocalStorage is not needed. But some possibility to pass data from a request, in Paraglide's case the locale, to the rendering process (which can happen via a global variable too btw if rendering and middleware would operate on the same thread) is needed.

Taking a look at the shared issue to see how we can help resolve the breaking 15 changes here 👀

If you find a way, many nextjs users will be happy.

A possibility I thought about is SSG the paths via opral/inlang-paraglide-js#433. That would require a programmatic API to inform NextJS about the localized paths for any route.

Maybe defining a catch all route would work? This match all path would receive the return value of generateStaticLocalizedUrls()?

// app/[...path].js

EDIT: even SSG would require some form of setting the locale before rendering begins. Passing the params is also an async operation.

Alternatively, NextJS could implement site crawling https://inlang.com/m/gerre34r/library-inlang-paraglideJs/server-side-rendering#site-crawling-invisible-anchor-tags to derive localized URLs.

[t6tv8e]

What is the current status of this?

Need to use paraglide for i18n.

[juliomuhlbauer]

I just switched to TanStack Start. Best decision

[KevinEonix]

unfortunately i think that the middleware is on a different process than the rest so the async local storage will not work.
In the current version (15.4.2) i saw that there is an experimental api to pass the middleware on the node env (FINALLY)

So there is a possibility to use redis or equivalent to store reusable data.
NB: i did not test it

[KevinEonix]

and for i18n, i use it with a cookie
and use the CookieStore API to reload the server component if the language change

[osdiab]

Correct me if I'm wrong, but based on the previous conversation, I think the problem is that regardless of how the locale is being transmitted, cookies(), headers(), and params all return Promises in recent NextJS versions.

Paraglide NextJS instructions have you assign a locale variable in your root layout to transmit the locale throughout the app, which won't work if it depends on awaiting a Promise, because child components can render before the Promise resolves, and so the locale wouldn't be reliably set.

Using redis sounds like it would have the same issue because getting data from it would also be async regardless. So sounds like unless something changes on NextJS's end there doesn't seem to be a good way to achieve this in the way that Paraglide approaches things.

(Unfortunately for my company, we can't just switch to TanStack Start even if they do get around to supporting RSC at some point, since we already have a large NextJS codebase; but platform issues like this is definitely enough to get me to use other frameworks for other greenfield projects.)