Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.

▲

conor- 4 days ago | parent [-]

I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all aggregated in one place using OTLP format

▲

camdenreslink 3 days ago | parent [-]

Just by bringing up k8s you are making their point. It should be dead simple to do logging without having to set up hardly anything. I shouldn't even need to know what a sidecar container is.

	▲	conor- 3 days ago \| parent [-]
		"dead simple" really depends on what you're targeting and how. If you're targeting a cloud deployment on hardware you don't control or that's running with multiple instances/replicas, OTEL makes that pretty simple because you get a lot for free in the way of tracking instances/correlation ids, etc. If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with) Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives