next-app-router-bleeding-edge

next-app-router-bleeding-edge.md

• Can't mix static layout and dynamic pages, this prevents define common static data requirements in the layout and then optionnally dynamic requirements in some pages below: vercel/next.js#44712 (comment)

• RSC might be a way to colocate graphql data requirements with components, but it's not very declarative

• i18n: since "FormattedMessage" tend to be a leaf component, we can't really server-side render it, all i18n messages thus need hydration

• 404 are delicate because route handlers can be mixed with routes : vercel/next.js#49696, and also when fetching files (you may conflate a file with the first route parameter of your app eg [lang])

• caching is URL param based or body-hash based, so not optimized for GraphQL caching that relies on the semantic of the graph (= the content of the request/response body, and not just a hash of it or the query parameters): https://prismic.io/blog/advanced-nextjs-server-context

• route handler bundle issues with PNPM symlinks: vercel/next.js#49696

• can't invalidate a dynamic route from server: vercel/next.js#49387 (comment)

• cannot call route handlers/API routes from RSC => annoying to use Express libraries like Passport or rate limiter : hoangvvo/next-connect#228

• 3rd party libs that send "fetch" calls "cache" config may not be configurable, see issue with @upstash/redis that prevents static rendering : upstash/redis-js#397