Dynamically use App Router pages or Route Handlers depending on the CMS

[ahtcx]

Hi,

My colleagues and I are in the process of migrating our sites to use App Router. We make a request to our CMS with the incoming URL that then returns the page content. There is no way of knowing ahead of time what kind of content the CMS will respond with, this could be normal site pages (using App Router) or it could be plain text, JSON etc.

Those kind of custom responses can only be achieved using Route Handlers, so we effectively have two possible entry points.

app
├── [[...path]]
│   └── page.tsx
└── dynamic
    └── [[...path]]
        └── route.ts

The way to solve this would be to move our CMS request out from the root server component and into middleware, where we could rewrite the response to be either the page.tsx or the route.ts depending on the content type.

The issue with this is that middleware is completely isolated from app router meaning we'd have to make the CMS request twice: first in the middleware then in the server component/route handler.

I've seen various hacky ways to somewhat work around this:

• forward data via headers
  • limited in size, not suitable for our use as the CMS responses can be quite large
• cache the request externally using something like Redis
  • increases stack complexity, not ideal
  • adds some overhead
• cache the request via a separate route handler
  • there's no non-hacky way to make requests to the route handler from the middleware
  • adds some overhead

I understand that the reason middleware is unable to directly pass data to the app router is because it's designed to be an Edge function, but we deploy our project as standalone and it all runs from within the same Docker image. I was hoping the newly introduced nodejs middleware runtime would resolve this but it seems the still run in completely separate processes.

I know our use case is very common and it's frustrating to rely on hacks to make it work for what should be simple. Maybe a new context.ts file could exist under app router directories allowing it to pick between using the page or route handler whilst providing initial "context" (in our case containing the CMS response) to them either via props or via a new argument/option in the route handler?

app
└── [[...path]]
    ├── context.ts
    ├── page.tsx
    └── route.ts

// context.ts
export default async function context({ params }) {
  const data = await getCmsData(await params);

  // pass the data to the route handler
  if (data.contentType !== "text/html") return Context.route(data);

  // pass the data to the page handler
  return Context.page(data);
}

Or maybe an option to run the middleware in the same node process as the rest, allowing us to create an in-process in-memory cache accessible to both?

Are there any plans to implement a solution to this problem? Or are there other cleaner ways of pulling this off?

Thanks

[ahuaiqom]

[ahtcx]

Thanks for proxying my question but I also have access to ChatGPT. You're not being as helpful as you think you are. I was specifically looking for some human answers. 🤖

[icyJoseph]

Are you self-hosting? And in full control of this app deploys and such?

---

Otherwise...

If we take a step back, maybe this take:

cache the request externally using something like Redis
increases stack complexity, not ideal
adds some overhead

Is kind of the way to go? Fill the key value look up Db with path -> type associations and use that to route. Yes it is an extra layer, and adds overhead, but it'll get the job done, and be predictable, easy to debug and likely maintain too.

As long as the latency of doing the look up is very low, this should be fine.

A less optimal solution would be to try and rely on the fetch cache layer, again, this kind of depends on how much control you have over the deployment, let's assume there's just one deployment, then you could handle all requests in a Route Handler, fetch with cache, so that the response is saved to the data cache, and if the content turns out to be a HTML, proxy to a server component page, and stream that back to the client.

You'd need to hide that server component page from direct access but it'd get the job done. The latency bulk would be in the one-maybe-two HTTP round trips (client -> route handler -> (possibly) to page -> route handler -> client). Since we relied on the fetch data cache, the page round trip would just read from there and start streaming the response back to the route handler, which in turn forwards that to the client.

[ahtcx]

I agree I think ultimately the low latency KV store is the route to go. It's frustrating there a no better solutions, it's the best and least hacky of a line-up of all bad solutions.

[icyJoseph]

If you are self-hosting, you can somewhat, store things in middleware to the global object, as long as you have nodejs runtime, but I wouldn't just attach things raw, you'd need to somehow create controlled access into this store - you might as well just use a key value store.

[ahtcx]

I tried that but even with the nodejs runtime they run in separate proccesses as far as I can tell.

[icyJoseph]

Try this, globalThis.foo = 100 in middleware w/ nodejs runtime, and then read that from a page. IIRC, it'll print 100. But if you attach a singleton, you'll end up with different singletons.

So you could have a global store in the global context, and pass some data through headers (already too complex haha), to read data from that global context within the page or route.

[ahtcx]

I stand corrected! I thought I'd tried this at some point but I guess not. Thanks!