# A Frustrated Next.js User Turns Middleware Logging Into a Framework Critique
By IO Digest Desk
A sharply worded developer essay about Next.js gained traction by focusing on a task that should have been routine: adding production-ready logging to a service.[16131]
The post starts with a concrete scenario. A Next.js service fails in production, default logging is only enabled in development, and the team needs request-aware logs.[16131] From there, the author argues that a straightforward observability task quickly turns into a tour of fragmented runtimes and missing extension points.
The first complaint is about middleware itself. The author says Next.js middleware can pass only four parameters and that only headers affect the invoked route.[16131] The post also argues that middleware composition is constrained, making it harder to build layered request processing in a style developers have long expected from frameworks such as Express.[16131]
That limitation pushes the author toward `AsyncLocalStorage`, a common Node.js mechanism for carrying request context. But the post says the initial middleware logger produced browser output rather than the expected server-side logging because Next.js middleware runs on the Edge runtime by default.[16131] Switching to the Node.js runtime helped in a fresh project, the author says, but did not work consistently in the real application.[16131]
The deeper frustration appears when logging moves beyond middleware into pages and layouts. According to the post, the logger function returned `null`, apparently because rendering was not happening within the same async context as middleware execution.[16131] The workaround, the author says, was to tunnel state through headers, because headers were effectively the only durable bridge from middleware into the route layer.[16131]
That workaround matters because it exposes the framework boundary the author finds most damaging. Middleware logging code cannot simply be imported into server code, and server logging code cannot simply be imported into middleware, the post says.[16131] Client components further complicate the picture because, despite the name, they also run on the server in some circumstances, creating what the author describes as a third split.[16131]
The essay then broadens from one logging problem to a critique of framework design. The author contrasts Next.js with SvelteKit, another Vercel-associated project, and praises SvelteKit’s middleware model for allowing richer data passing and real objects such as a logger.[16131] In the author’s telling, the comparison makes Next.js feel less like an opinionated framework and more like a tightly controlled environment where core capabilities are available to the framework authors but not to users.[16131]
The GitHub issue tracker becomes part of that indictment. The post claims there are many long-standing issues with heavy community engagement but no official response for years, and cites two specific bug reports the author says received no answer after working reproductions were provided.[16131] The point is not just that bugs exist. It is that developers feel they cannot reliably predict when pain points will be acknowledged, let alone fixed.
As evidence, this is one developer’s argument rather than a platform benchmark or official incident report. Still, the piece resonated because it isolates a common source of framework fatigue: the moment when productivity abstractions stop feeling like leverage and start feeling like hard walls. Request-scoped logging is not an edge-case luxury. It is basic operational plumbing. When that plumbing becomes awkward, developers naturally start questioning everything built on top of it.
The supplied source supports a narrow but relevant conclusion. This was a developer-led critique of Next.js framed through one practical task, and the task exposed concerns about middleware ergonomics, runtime fragmentation, and support responsiveness that are likely familiar to many teams using the framework at scale.[16131]
