←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 3 comments | | HN request time: 0.049s | source
Show context
Rauchg ◴[] No.45100460[source]
Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time.

If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It’s also a somewhat advanced escape hatch.

Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention[2]

[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable

[2] https://nextjs.org/docs/app/api-reference/file-conventions/i...

replies(8): >>45100602 #>>45100630 #>>45100658 #>>45100894 #>>45101395 #>>45101475 #>>45104120 #>>45108837 #
throwaway150 ◴[] No.45100630[source]
Appreciate the response. But ...

> Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention

That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way? This can't be such a hard problem, can it? Every other language and framework does it!

replies(1): >>45103756 #
conor- ◴[] No.45103756[source]
> Why can’t logger().info() just work in a sensible way?

I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff?

If you view that as being overkill, perhaps you're not the target audience of the framework

[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...

replies(2): >>45104246 #>>45105306 #
tacker2000 ◴[] No.45104246[source]
Again, why would one need such a heavyweight tool?

Most frameworks have powerful loggers out of the box, like Monolog in the PHP world.

replies(1): >>45108734 #
1. conor- ◴[] No.45108734[source]
What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack

There's even a handler for monolog in PHP - they are not necessarily mutually exclusive

https://github.com/open-telemetry/opentelemetry-php/blob/mai...

replies(1): >>45118360 #
2. tacker2000 ◴[] No.45118360[source]
Yes but instead of just logging to a text file for example you need OTEL, thats my point.

The fact that Monolog has a handler for this tool isnt relevant, but it shows that there is one more layer of complexity tacked on.

replies(1): >>45121558 #
3. conor- ◴[] No.45121558[source]
That doesn't really mean it's heavyweight though; an extra layer, sure (but I don't even really agree that it's complex - you set it up once and then mostly just log the same way you would with any other).

You can still log to a text file if you want to run locally, but for something like next.js where you're intended to deploy production to some cloud somewhere (probably serverless) the option of _just_ writing to a text file doesn't really exist. So having OTEL as an ootb supported way to do o11y is much better than the alternative of getting sucked into some vendor-specific garbage like datadog or newrelic