10 common mistakes with the Next.js App Router | Highlights and Annotations by Gistr.

on every single request now there's two opportunities here to better understand how this model works. the first is understanding the difference between local and production so in local even though this data is cash which I'm going to get to in a second you're going to get a new value it's going to get recreated on every single request and secondly is understanding why this is cashed by default So let me show the first one Let me open up my terminal and I'm going to run um, run build and run starts. so I'm going to do a production build of my application and then I'm going to start up my local dev server my production server on my local host. So now if I go back to here and I reload the page It never changes. So this is a difference between how your local uh your local deb environment is working through next dev versus doing that production build and then serving your production server. Now the question is why does it work this way? Well, this is actually pretty powerful If you understand more of the intention behind it, a route handler is the base of how pages work inside of the app router as well too And pages can be cached by default. So even if I'm doing an asynchronous component or a server component and I'm fetching some external data that doesn't necessarily have to run on demand on every single request. it's kind of like instead of a server component, it's a data component Because you can fetch data. You can pre-render a page that only was pre-rendered on the server and then you don't have to have any additional client.js for that long story short, the options for how route handlers work are the same as pages. So by default, this is cached static, which means that anything that I do here to opt into making this dynamic,