You can move the auth check to a middleware

which lets you statically render your paid content without checking user authentication in the actual next app (page or layout)

auth is made up front

you can use Next middleware but also any kind of proxy you want, like nginx etc.

if you don't use serverless, this also work with a custom server https://nextjs.org/docs/pages/building-your-application/configuring/custom-server

This pattern is for caching the whole rendered page

a slightly simpler alternative is just to use a shared cache for the data

like "node-cache" or Next.js "unstable_cache"

if you use node-cache, be careful to cache the promise to the data (and not the data) to be able to properly handle parallel calls

this means your page will rerender on each request, but the data will be there immediately

Hi Eric! Thank you for your answer.
I think segmented rendering would not work in my case. We’re using a standalone backend for the APIs which expects a bearer token. I will look into custom server and unstable_cache or node-cache.
Thanks again!

I’m wondering if this can be done using the custom cache handler. Someone created a patch for Next.js but obviously this might break with updates. I’m seeing if it’s possible to apply that logic in the cache handler.

https://github.com/vercel/next.js/discussions/51279#discussioncomment-7808543

Custom cache handler is to manage the distribution of your computations

so not really your issue here

it's like when you self-host and want a Redis to store cached data rather relying on Vercel built-in cache distribution system

Your issue seems different than this post though

"All my users see the same list of items" that's your issue

this post is a bit different, it's more "I need a fetch call to a private API from an RSC"

so in your case segmented rendering will make sense

but you may indeed still also have to setup cache manually to take the authorization headers into account

no sorry actually the question is the same but it indeeds conflates these 2 issues, I'll update my answer there

Thanks again! Btw just as an FYI I’m the same person who asked on Reddit and opened a GitHub discussion about the topic (not the one linked, this one: https://github.com/vercel/next.js/discussions/61656).

1- Would segmentation work for me if the Django REST API requires an authorization header ? (For the list of item accessible to logged in users but is the same for all users). I know I can cache the data alone but I was hoping to cache the entire HTML.

2- From what I understand, using force-cache with an Authorization header will cache the data but only for that bearer token. I was hoping to use the “patch” in the GitHub link above and use the same approach to key the cache per organization id(or some sort of token for added security) when I pass a particular parameter to the fetch function.

Yeah I figured haha

To clarify. I was hoping to use the logic in the patch but implement it in the custom handler

Yeah haha didn’t want to waste your time and have you answer in 3 places P

yeah so 1- Django REST API requires an authorization header => is it user specific, or for authenticating your Next app?

2- just manage a cache yourself, unstable_cache will do or node-cache

there is no possibility or caching per group of users built-in Next

or any other framework

they do either static (meaning public static, same for everybody) or dynamic but for anything in between you need to manage the cache key on your own basically

1- User specific
2- Noted! I’ll learn how to use those. I take it I’m misunderstanding the purpose of the custom handler, i thought I might be able to manipulate the key handling there.

yeah ok so the key is user specific, but multiple users get the same data

I would suggest crafting an additional org key for server authentication

the problem is that you are using user A key to get content for B & C for instance

ideally instead you'd treat your Next app as client to your Django server

usually done via an API key

and then you treat user specific auth as a separate problem, that you can handle with a segmented render

but if you don't have the leeway to do that then just setting up your own cache will be fine I think, it's not abnormal

Yeah basically 2 tiers:
1- Common data for everyone but needs to be logged in. (Django expects a bearer token for the request).
2- Common data for all users within the same organization.

Yeah for now I guess I have to go with the custom cache. Can do the ideal scenario after our soft launch

Thanks a lot!