It's not just you, Next.js is getting harder to use - PropelAuth

I wrote a blog post the other day about how Next.js Middleware can be useful for working around some of the restrictions imposed by server components. ... From my perspective, Next.js’ App Router has two major problems that make it difficult to adopt: … While exposing the request/response is very powerful, these objects are inherently **dynamic** and affect the entire route. This limits the framework's ability to implement current (caching and streaming) and future (Partial Prerendering) optimizations. > To address this challenge, we considered exposing the request object and tracking where it's being accessed (e.g. using a proxy). But this would make it harder to track how the methods were being used in your code base, and could lead developers to unintentionally opting into dynamic rendering. > Instead, we exposed specific methods from the Web Request API, unifying and optimizing each for usage in different contexts: Components, Server Actions, Route Handlers, and Middleware. … ... It’s not that it’s necessarily incorrect - it’s unexpected. That original post also mentioned a few other subtleties. One common footgun is in how cookies are handled. You can call `cookies().set("key", "value")` anywhere and it will type-check, but in some cases it will fail at runtime. Compare these to the “old” way of doing things where you got a big `request` object and could do anything you wanted on the server, and it’s fair to say that there’s been a jump in complexity. I also need to point out that the “on-by-default” aggressive caching is a rough experience. I’d argue that way more people expect to opt-in to caching rather than dig through a lot of documentation to figure out how to opt-out. … ## Just because something is recommended, doesn’t mean it’s right for you One of my biggest issues with the App Router was just this: Next.js has officially recommended that you use the App Router since before it was honestly ready for production use. Next.js doesn’t have a recommendation on whether TypeScript, ESLint, or Tailwind are right for your project (despite providing defaults of Yes on TS/ESLint, No to Tailwind - sorry Tailwind fans), but absolutely believes you should be using the App Router. The official React docs don’t share the same sentiment. They currently recommend the Pages Router and describe the App Router as a “Bleeding-edge React Framework.” When you look at the App Router through that lens, it makes way more sense. Instead of thinking of it as the recommended default for React, you can think of it more like a beta release. The experience is more complicated and some things that were easy are now hard/impossible, but what else would you expect from something that’s still “Bleeding-edge?”