Use getStaticProps and getServerSideProps together

[izziaraffaele]

As far as I understood the new data fetching strategies getStaticProps and getServerSideProps introduced with the RFC #9524 are mutually exclusive but I believe there are many cases where we could enjoy the benefits of both of these approaches.

Let's say I want to build a page where most of the content is static and could be loaded at build-time, but there is a small portion of data that must be loaded at request-time and for SEO reasons the whole page must be rendered server-side. This could be the case of a homepage of multilanguage e-commerces or marketplaces where most of the content is static and could be fetched at build-time based on a provided language but the "featured product" section must always be loaded with the most updated content per request.

Right now the only solutions I can think of to keep TTFB low and avoid fetching static content on each request are:

1. Fetch static content at build-time running a customized script which will save data in a JSON file, which will be load later in getServerSideProps together with dynamic content or imported as a module

2. Fetch both static and dynamic content in getServerSideProps and use a custom cache layer to cache only static content for future requests.

Both solutions force developers to write custom caching logic and/or DevOps strategies to build and deploy this kind of application, while it could be easier if we could just use getStaticProps and getServerSideProps together. In this scenario, static content could be loaded at build-time using getStaticProps while dynamic content used for server-side rendering will be loaded per-request using getServerSideProps. In the case, we are not enjoying the full benefits of SSG pages but we can still reduce TTFB by loading static content only once at build-time.

What do you think about this solution? Could it be a new proposal for an RFC? Are there any other solutions I haven't considered?

[janus-reith]

It might help if you give a specific example - I can't really thing of any usecase, except if you might actually have data on the server which must necessarily be send alongside your rendered page somehow instead of doing a simple client-side fetch(Is that what you`re looking for?).

For the actual performance benefit of serving a static page, the whole approach certainly imposes the constraint that your data on the server which I guess you want to fetch in getServerSideProps can't mutate the rendered page, as that would mean another render and therefore increased server response time - For that you still have getServerSideProps or getInitialProps like before.

If you have additional data available on the server which you want to use, expose it over an api endpoint and fetch that on the client.

In theory there might actually be a possible approach where you could stitch together a big part of static page data with a small portion that relies on dynamic data into one page - But besides the added complexity making this approach prone to a lot of errors, a full static page can always be served faster (and more performant), leaving enough time then on the client to fetch additional data once it recieved the instruction to do that from a script in that server response.

Getting back to the initial theory, where you send server data alongside your page, the issue here would proably be that in nearly all cases, the static html data is available sooner than your server function could execute, meaning that waiting for the function to complete would result in an additional delay.

That's how I understood things so far, but I stand corrected.

[Vadorequest]

In other words, you'd like parts of the same page to be statically pre-generated, and other parts to be dynamically generated from the server?

[izziaraffaele]

Not really, the page could be dynamically generated from the server as it needs to load dynamic data per-request but, for static content only, it will use also the result of getStaticProps which will be loaded once at build-time and reused every time the page is requested.

In the end, the page component will get data from both getStaticProps(loaded once at build time) and getServerProps (loaded on every request) as props.

[codeyourwayup]

I think getStaticProps with "revalidate" would suffice your need, you can make the revalidate timeout very short, for example 2 seconds. Doing so, it will be quick enough to catch your real-time data changes in the database, but also without performance loss. Because, the revalidation is happening in the background, after the timeout is reached. See details https://reactions-demo.vercel.app/

[JohnLockwood]

I have another use case for this (I think) or at least would like to suggest one and maybe get some thoughts on how to implement it correctly. (I'm new to NextJS, so if there's an obvious solution feel free to dumb it down -- it might not be obvious to ME yet. :) )

The use case is a set of learning materials (lessons), for which the most logical organization is one page per lesson, with various page elements (video, audio, text, exercises, etc.) making up the lesson. Add to this the requirement of having partial content offered free, and other parts of the page available to premium subscribers. Both types can benefit from pre-rendering, but the "open" free stuff items can be rendered at build time, while the "behind the paywall" stuff should only be shown to authenticated/authorized users, but should still low TTFB and crawlable to non-human users.

I suppose this could be handled by separate pages with redirects or some other means, but none of the ideas I can come up with offhand is very elegant (if it would even work). Any thoughts?

ADDENDUM:

I've since found https://github.com/vvo/next-iron-session which may provide an answer for this use case, but I'm still working through it. Meantime I'm open to comments if there are other ideas. Thanks.

[developer-ta]

To make a page both dynamic and static at the same time is possible.
the solution for dynamic: you have to use react useState then useEffect to send the request after unloading fishing on the client side
but first must use next.js api getStaticProps() make the page static when user's first visit

[seanconnollydev]

I am in need of the ability to execute some middleware on the server to restrict access to static content. The ability to use getStaticProps and getServerSideProps simultaneously would help but I actually think the middleware proposed in this RFC would also do the trick:

export async function getStaticProps() {
  // Return content data from prismic.io or some other CMS
}

export async function middleware({req, res}: PageContext) {
  // Redirect if user is not entitled to view content
}

[izziaraffaele]

Could you please link the RFC?

[seanconnollydev]

🤦 sorry about that
#7208

[seanconnollydev]

For me there is value in build time data fetching with runtime rendering.

…

On Wed, Jun 3, 2020, 8:35 AM Raffaele ***@***.***> wrote: Not really, the page could be dynamically generated from the server as it needs to load dynamic data per-request but, for static content only, it will use also the result of getStaticProps which will be loaded once at build-time and reused every time the page is requested. In the end, the page component will get data from both getStaticProps(loaded once at build time) and getServerProps (loaded on every request) as props. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11424 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWY34IPWJFUEFKHJT22NEDRUZNR7ANCNFSM4LVP62VA> .

[fimbault]

Hello,

using nextjs 10 it seems we have the same issue (here with prisma and meilisearch as a usecase but can be very common).
#19606 (it works locally but not on vercel)

What can we do about this ? If it's not possible, is there a suggested workaround ?
Thanks

[pmh722]

I have same request. FYI this is the one issue preventing me from hosting on Vercel, if I can't figure out an alternative solution.

My use case: Paywalled publication. The pages are all static and the core content is fully known at build time. But for reasons of paywall integrity, it's important that no content hits the client computer unless the auth cookie is first inspected and approved server side.

What I'd like to do is have getStaticProps generate all the content at build time, so it's ready to quickly serve after authentication, and then getServerSideProps only has to inspect the auth cookie. But right now I have to choose between the two.

If the page uses getStaticProps, I can't authenticate server side before the content gets delivered to the client. If I understand the docs correctly, it seems the official solution (https://nextjs.org/docs/authentication#authenticating-statically-generated-pages) is to use client side JS to fetch the gated content after authenticating. But for my use case, most of the content is gated. It's not just eg a username and some dashboard numbers. So I lose the whole point of an SSG framework.

Likewise, I could use getServerSideProps for the whole page, but again, then I don't get any static site generation benefits.

Other than combining getStaticProps and getServerSideProps on the same page, an alternative solution would be if I could check cookies in some route/middleware script. That way I could intercept unauthenticated users before they got served the gated content. I believe there's been talk of this feature as well.

Is there some other NextJS / Vercel solution for this use case I'm not aware of? Or is it just fundamentally impossible to combine server side authentication with SSG content?

I'm also looking at a Cloudflare Workers solution, where I would use some vanilla SSG (NextJS or otherwise), upload the resulting static assets to Workers KV, and then use a Worker to inspect the cookie at request time before serving the static content.

[pmh722]

I would even be fine with a solution that sacrifices my ability to put paywalled content in the Vercel CDN. I realize that edge compute functions are a more exotic capability, and checking auth in a CDN built for static assets is really hard.

But it seems untenable to rebuild each article from scratch on each request. I can't put markdown/MDX conversion inside getServerSideProps. That would be crazy slow, right?

Another possible solution would be adding some custom build-time script that converted the raw markdown content into static site assets, that stay in a private folder the public cannot access directly, but is accessible by a public page's getServerSideProps. It seems doable but I'm hesitant to hack together a second parallel build-time tool-chain that's not natively integrated with the NextJS "magic" functionality. Is there any example, tutorial, or recommended approach along these lines, sanctioned by Vercel, that won't break anything in the framework?

Thanks, keep up the excellent work. NextJS seems like an exciting project and I'm hopeful to find a way to work with it in my company.

[JeroenReumkens]

I'm looking for the exact same solution for weeks now. As far as I know there still isn't a solution to this yet. However, since I keep finding more people who need/want this, I have good hopes that one day they will implement a feature like this 😬

[lazlothemonkey]

I am facing the same exact issue, trying to auth guard relatively static pages using markdown stored in local file system. Have you figured out a solution yet? I think the build-time script option seems the most straight-forward, but have you figured out how to do it?

[pmh722]

I ended up doing export to static site, then upload the static content to CloudFlare workers, with a quick workers script to check auth. (I actually used 11ty for the static site, because I don't think Next.js was built with that architecture in mind, and I didn't want to break anything. If you just need to turn markdown into HTML without any client side react, check out 11ty, it may be enough for your use case. I feel bad promoting a competing framework in the Next.js discussions page! Next.js does seem like an excellent project overall but I do think the "auth for static content" story is currently missing, as you can see from the various posts in this thread.)

[timuric]

I have another use case that has a similar bottleneck. We have a catalogue of 30 product categories, in 5 languages, in 30 different countries with various stock and currency availability, which I believe quite a typical example of a mid size e-commerce shop. The issue is that there are 4500 possible permutations of getStaticProps for the catalogue page. While stock availability can change quite often, the content and translations are rarely changing. Eventually using getStaticProps becomes not scalable without using custom caching layers for CMS and translation services. It would be great to have a way to separate static (nearly static) and dynamic sources.

[karpolan]

Use diferent sub-domains for different languages+countries. It is even bvetter for SEO :)

[timuric]

That’s actually not the case anymore (at least with google) and the downside is that it makes redirects slower as well caching strategy less efficient or would create extra domain resolution time.

[vforvalerio87]

Use diferent sub-domains for different languages+countries. It is even bvetter for SEO :)

Then you make a fix in the header or footer, need to recompile every page and you are looking at 60 hours of build time

[laravelman]

I have a use case that need to list post details Static and to show comments from Server Side as they keep updating.

[timfuhrmann]

You can still serve dynamic content (your comments) using getStaticProps alone: Incremental Static Regeneration

[vforvalerio87]

You can still serve dynamic content (your comments) using getStaticProps alone: Incremental Static Regeneration

Assume 100 page visits per second, that's gonna be like 100 API calls per second to get the comments (in a pure "getServerSideProps" scenario). Assume 5000 pages (which is not particularly insane... I have a 400000 (four hundred thousand) products ecommerce in 8 langauges), that's gonna be 5000 API calls + re-building 5000 pages every second?

To put it mildly, it's sub-optimal, unnecessary and simply not the right way to approach the problem from an engineering standpoint. To put it more realistically, it's insane and unfeasible.

[SleeplessByte]

It's not goint to query all 5000 pages every second? It's only going to query it when someone visits the page.

[vforvalerio87]

It's not going to be "when someone visits the page". The whole point of ISR (incremental static regeneration) is that the website re-builds itself periodically to serve static content to the end users

[Vadorequest]

@vforvalerio87 Nope, you don't fully understand how it works. I suggest watching https://www.youtube.com/watch?v=eMwTEo6AjDc&ab_channel=LeeRobinson which explains it very well.

TLDR; ISR pages are only rendered when a request is received, if the page is older than the configured threshold.

Another example that might help you: https://nrn-v2-mst-aptd-at-lcz-sty-c1.vercel.app/fr/demo/native-features/example-with-ssg-and-revalidate

[ajjack50n]

I would like to build a form layout based on a sequel ORM model and then populate the form on every page request. This feels like an elegant way to keep both the ORM model and HTML form layout in sync.

[bendman]

There are a lot of arguments against this feature, but it seems logical to me that if there is an argument for getServerSideProps then there is an argument for using it with getStaticProps. Any page that would reasonably use getServerSideProps might additionally include a heavy request for relatively static data.

So either getServerSideProps isn't useful, or it's acceptable to waste power and time making heavy requests for static data inside of getServerSideProps alongside dynamic data.

It could be that getServerSideProps is used much more frequently than intended, but if that is the case there should be a note in the documentation that encourages people to use getStaticProps with the invalidated flag instead of having any truly dynamic data on the server.

[vforvalerio87]

I mean, to be honest it is a use case that must be supported if you want any kind of widespread adoption.

getStaticProps and getStaticPaths + getStaticProps are mighty fine when the paths are known at compile time and are a reasonable number.

If you are working on a 8 language e-commerce with 400 thousand products per sub-site where content needs to be either statically generated or computed at server time (my current use case), you are going to want to use server side rendering.

Right now I'm in the situation where product and category listings are computed using getServerSideProps, everything else is done via getStaticProps (possibly in combination with getStaticPaths), and stuff which we are computing at compile time (and later revalidating via ISR) for every page via getStaticProps, is instead computed via getServerSideProps in pages that are generated at runtime, making them significantly slower than they actually need to be (and hitting more API endpoints than they need to, way more often than they must).

[u382514]

I think overhauling getStaticProps/getServerSideProps to incorporate this would be a nightmare. Plus it would mess up all the pretty documentation.

I'd just be happy with some lifecycle/middleware functions to use to allow one last server side shot to make a decision....especially where it concerns authentication and redirects. Essentially ALL pages are server side rendered, it's just that the static ones are pre rendered. It still has to make the roundtrip to the server to retrieve what's already there. A beforeSSR and afterSSR would be mighty helpful in doing minor checks and balances, logging, redirecting or flat out cancelling the request and possibly saving on some gnarly SSR logic.

Any content managed by a CDN is a completely different architecture and even that has authorization at the edge for the major cloud services.

Lifecycle hooks would also help discourage abuse of overloading business logic or long running tasks that are not asynced. That's what getServerSideProps is for.

[izziaraffaele]

But this way you still need to use some kind of custom logic to cache static content within those hooks to avoid re-fetching it every time the page needs to be rendered on the server.

The overall goal of this discussion is to keep the page SSR rendered so that we can fetch dynamic data and render the most updated UI but, at the same time, we want to cache static content at build time to reduce TTFB and to avoid reloading data that never change.

[CaptainN]

This could be done in a straight forward way. Basically, getStaticProps (with revalidate) is the first in the pipeline, and runs at build time, and has no access to query params. Great for building the page and json for paramless page access.

For getServerSideProps next could deliver the static props to that function, and then that data could be mutated as needed for the SSR request, based on query params.

In this way, the queries that don't change even with query params could still be cached, and only new queries that change based on query params (like pagination) would be run in SSR.

Seems like that'd be very manageable.

[danielcolinjames]

I think @bendman described my situation and how I found this discussion the best:

Any page that would reasonably use getServerSideProps might additionally include a heavy request for relatively static data.

So either getServerSideProps isn't useful, or it's acceptable to waste power and time making heavy requests for static data inside of getServerSideProps alongside dynamic data.

I have a site where I want parts of the data fetching to be dynamic and up-to-date (not just the "the next visitor will get up-to-date data" functionality that getStaticProps with revalidate gets you) for meta tags and current information. So I have to use getServerSideProps for that. But inside that function, the first request is a large list that is required to make all the other requests. And that first request I would love to be able to do statically separately from the rest of getServerSideProps, since it doesn't need to run every time the page gets requested.

To describe my specific example, it's this site: ath.ooo. Every crypto asset ticker symbol has a page, e.g. ath.ooo/BTC. So my data fetching has to start by pulling a list of all crypto assets in CoinGecko's database so it can map between ticker symbols and the unique IDs CoinGecko uses for each asset (since ticker symbols can overlap). So the other requests I have to make in getServerSideProps are dependent on that first request. But that first request could easily be cached every 24 hours or so, since it won't change very often. The site is actually serving 500 errors regularly because that particular list endpoint seems to be erroring out (probably because requesting that list from the server side for every page visit is causing CoinGecko to rate limit my site and the Vercel server that is hosting it).

But overall I know data fetching stuff is pretty complicated, and maybe what I'm describing is something that just doesn't fit within the paradigm or abstraction that the Next team has created. (If anyone has suggestions for my specific situation I'm all ears.)

[Vadorequest]

I've done something similar using https://github.com/ricokahler/next-plugin-preval for i18n data that are static and shared amongst all pages, while each page could have its own dynamic data (real time).

https://github.com/UnlyEd/next-right-now/pull/337/files

Used the same logic (actually, I did this first) to avoid generating pages for locales that weren't enabled by the customer (customer = tenant, owns a whole website).

UnlyEd/next-right-now#334

I met several issues related to the plugin itself, the author has made some improvements since then.
Also, worth noting I've disabled plugin in dev because it overfetches instead of fetching only one, but it works great on staging/production.

I would very much like to see something like that built-in, indeed.

[dustinsgoodman]

I think I might have a more simple example of why this is necessary. I have a report page that has both static and dynamic content. The static content is stuff that I would like to pull from my internalization library. The dynamic content is data for a report page. I'd love to be able to render the report localized to the current user while still feeding them the data they requested.

Per the Next docs recommendation, we're using next-intl. next-intl suggests loading your translations through getStaticProps and then uses a hook to render the appropriate translation for the page. See https://github.com/amannn/next-intl/blob/main/docs/installation.md.

Of course, our report is rendered client side the first time it's loaded through a next/link but users can reload the report directly. At that point, we don't want to have to build a loader for that use case and just want to render the content in place which would require getServerSideProps to refetch the relevant data.

Without the ability to use both methods for data fetch, I have to get creative with the legacy getInitialProps or some other trick to render the translations at the root of the app and pass them around either through state or some other mechanism.

[clement-faure]

Same problem here using https://github.com/isaachinman/next-i18next. I would like to fetch currentUser on server side but i can't due to the fact that all pages are using getStaticProps to get translation at build time.

[a0972199950]

Facing same problem with you

[bryanltobing]

facing the same issue here due to translation that using getStaticProps

[mbrowne]

One alternative option to consider (not sure how well it will work for people's specific use cases here) - you can use getServerSideProps but set cache headers specific to that page to cache it with a CDN, which allows the rest of your SSR pages to remain un-cached. Of course you would only want to do this if the data you're returning doesn't contain anything specific to the logged-in user (although fancier caching strategies where you actually cache bits of data for each user are also possible). Example:

export async function getServerSideProps(ctx: GetServerSidePropsContext) {
    ctx.res.setHeader(
        'Cache-Control',
        'public, max-age=300, s-maxage=300, stale-while-revalidate=60'
    )
    return {
        props: {
            ...
        },
    }
}

[bryanltobing]

my use case here is to have my translation always static and only be generated at build time. but on every page, I also want to validate for user auth in server-side using getServerSideProps. This is what I imagined it would be. I'm using next-i18next

this will be used on every page to load translation

export const getStaticProps: GetStaticProps = async ({ locale, params }) => {
  return {
    props: {
      params,
      ...(locale &&
        (await serverSideTranslations(locale, ["common", "error"]))),
    },
  };
};

export const getServerSideProps: GetServerSideProps = async () => {
  if (!userAuthenticated) {
    return {
      redirect: {
        permanent: false,
        destination: "/login",
      },
      props: {},
    };
  }

  return {
    props: {},
  };
};

[timfuhrmann]

Another problem we are currently facing - and please enlighten me if there already is another, better approach - is that we are building an intranet that lives behind a Single-Sign On which provides a cookie including a JWT token. This token can easily be verified using getServerSideProps for every page on demand and a redirect can be triggered if necessary.

Since the intranet obviously contains a lot of data, our desired solution would have been to get all data such as news on build using static site generation and authenticate the user server-side on demand, which currently is not possible, since unfortunately getStaticProps and getServiersideProps don't like each other.

[timuric]

If you use something like Cloudflare you could use workers https://workers.cloudflare.com/ which would verify every request and would do a redirect if necessary. The advantage is that workers run on edge so they are going to be much snappier than running lambda functions on every request.

[pmh722]

you could use workers https://workers.cloudflare.com/ which would verify every request and would do a redirect if necessary

This is what I did. Works great for my use case. Just beware that then Next.js isn't aware of your auth layer, and may try to, for example, pre fetch some protected asset for an inauthenticated user. Putting auth in cloudflare and then serving static site only works if the static site is super simple. And then you lose a lot of the advantages of Next.js vs a simpler solution.

I still think combining static and runtime props on single page, or a routing middleware solution directly integrated into the Next.js / Vercel ecosystem, would be cool :)

[BrianHung]

Another use case: using getStaticProps to fetch restaurant menu data, and then using getServerSideProps to check whether the restaurant is open or not at the time of request to allow or prevent online ordering.

Right now, I'm running into a className mismatch because at build time, the restaurant could be open (or closed), but closed (or open) when a user requests the website. I would like to use getServerSideProps to avoid a flicking between these two states if the solution of a double-rendering is used:

Render the same thing initially
Render an update on mount

To dig into the example, you can also imagine restaurant menu data which never changes so getStaticProps fits, and then quantity of remaining restaurant quantities which frequently changes so getServerSideProps. Could also use an e-commerce example.

[kristijorgji]

This is very useful and is needed by us too.
Use case:
Let consider one url like domain.com/posts

1. We need statically generated page in built time for guest users (this is working fine now)
2. For logged in users only, we want to show a different list not used the static generated page for this url

Can this be done currently ?
In theory this can be done by conditionally using getServerSideProps in addition to getStaticProps
it would work like this
if (isuserlogged)
define getServerSideProps (or use it and override the props then component will render something else)
else
return whatever was already build by static generator

[cmmartin]

A simple use case for this...

We have a blog on our site that is generated with markdown files. The markdown parsing should obviously happen in getStaticProps and not on every request.

However, the blog has a header that is shared across all pages which shows a user avatar when you are signed in and a sign in button when you are not. We fetch the auth info in getServerSideProps

So, we need a special header for the blog that doesn't contain any auth info or "sign in" button, because we can't show already signed in users a "sign in" button

[u382514]

I ended up forking the repository and adding a new component static function called 'beforeGetProps' that is called on every request in renderToResponseWithComponent in next-server.ts. It acts more like a lifecycle event so as to not mangle up the standard next workflow. It was surprisingly trivial. The build process doesn't run through the same path so it doesn't creep in when building the static pages. The function allows 3 different returns; Redirect, Not Found, RenderServerSide (where renderServerSide is a function that acts as an adhoc getServerSideProps).

This allowed us to have static pages while solving the following problems:

• Ability to check auth (we're using Next-Auth) and redirect to the signon page, etc).
• Ability to check incoming querystring and decide to SSR this particular page rather than serve the cached version since Next can't handle querystring. This allowed us to not have weird nested/duplicated pages or trying to hack it through rewrites for simple logic based on querystring.

I know this doesn't solve all cases stated in this post but could be helpful for those with issues like we've had above.

Some folks have mentioned dynamic data that needs to be injected into SRR pages but that seems like an anti-pattern and it's not something that React even handles in their SSR offerings. Since Next is basically just caching the result of Reacts SSR functions I don't think it's feasible to get both dynamic and static when requesting a page from the server. You either SSR and return the entire app, as is, or you don't. Maybe there's some smart people working on that but, in the meantime, SSR isn't replacing the fact that you have a client side application running and that you'll have to add client side logic for that dynamic data, inevitably dealing with a loading indicator.

For Next Contributors: As for the separation of getStaticProps and getServerSideProps, It seems counterproductive. Since every request is inevitably checking and forking based on which one is present it doesn't make any sense to have these split. These functions can be merged under one and just pass a param letting the developer know where in the process it's coming from (build process vs dev server vs prod server) and then allow us to serve up the cached page vs a new SSR by simply noting that in the props returned. That gives the developer much more freedom to determine how the system behaves.

[pmh722]

That sounds awesome!

Question: In your pattern, is auth checked before the static page gets pre fetched? (I'm not familiar enough with NextJS internals to know the answer from your description...) My fear would be that the SPA aggressively preloads the post-auth static content when the link comes into viewport, and only runs the "check auth" once the link is clicked? And even if it works as expected today, future changes in NextJS implementation internals may change the answer?

It would be awesome if we could upstream something like "beforeGetProps" into NextJS main, so that it works with all the framework's behind-the-scenes magic...

Kudos!

[u382514]

@pmh722 From the code perspective, beforeGetProps runs prior to next-server fetching from it's cache. In fact, since I didn't want to trample on nexts code as much as possible, the renderServerSide prop/function runs the doRender which produces a cacheEntry and then I just skip over their cacheEntry logic and continues the main logic using my cacheEntry (which never actually gets placed in the Next.JS cache since it's essentially viewed as a getServerSideProp routine).

As for the browser side, it seems that next is using code splitting on its pages (via webpack magic?) and only sends over the needed js chunk when you request the page. So since it's behind auth and would get redirected to the signin page it never has a chance to load the chunk that contains all of the data. At least thats what it seems like when I'm checking the source downloaded in developer tools. Anybody, please feel free to correct me here.

As for getting this upstream I really think NextJS devs should consider getting rid of the concept of the split Static/Server side methods. I've been all through this code and it seems that getServerSideProps logic was kind of just copy and pasted from getStaticProps and then a whole lot of work was done getting the logic to split down the respective path in build and serving. Merging these and giving more information within the one function on where the process is at would essentially make my 'beforeGetProps' method unnecessary and probably make the main codebase a lot cleaner and easier to unit test.

[GMaiolo]

Does version 12 introduce anything that could help achieve this? I'm thinking about Edge functions or React Server Components (alpha) somehow

[pmh722]

I haven't tested it yet, but it does seem like the new middleware functionality can cover a lot of these use cases, where you need just a little request-time logic in front of a mostly static page. Thanks Vercel!

https://nextjs.org/blog/next-12#introducing-middleware

[izziaraffaele]

I don't think middleware/path-forwarding alone can solve my original issue subject of this discussion, but it can be a solution for other cases mentioned by other people here.

React Server Components looks promising though I haven't had time to try it yet.

[willemmulder]

We would love to have this as well. getStaticProps for the static data on the page (a course, a blogpost or other piece of paid content) and then getServerSideProps for authentication/authorization and personalization. Is there a specific rationale for not supporting this @timneutkens?

[willemmulder]

Yes, I've been thinking about that as well. I guess the authentication part should work, but I wonder how I could do the personalization part? I.e. passing the session and related info to the page as props?

[chirag-droid]

Yes, I also need serverSideProps for passing the session and applying user preferences, but the data itself is statically loaded

[mbrowne]

If middleware had the ability to inject a little bit of custom HTML in the <head> section of the page, that could also solve this. Currently it looks like the only way to send data from middleware to your app would be by adding a request header or cookie, which obviously wouldn't be a secure or practical way to send sensitive data or larger data.

[JeroenReumkens]

@willemmulder I guess I stopped reading at 'authentication', so didn't see the personalisation. My bad ;) Personalisation could be harder — it depends on what you want to achieve. If it is more of an AB-test (variants known beforehand), you might be able to pre-generate multiple pages, and show a different template in the middleware based on the user.

This example could be used as inspiration: https://www.youtube.com/watch?v=zRWZK1wIiao
Github of the video: https://github.com/BuilderIO/nextjs-builder-edge-personalization

[willemmulder]

@JeroenReumkens No problem ;-) It's more than an AB test though, it's personalization on the user level. But the same mechanism might just work for users as well... Maybe if we do a rewrite based on the user and redirect to e.g. \somePage\[userId]. A [...userId].tsx page would pick that up and use ISR (with 5 second invalidation) to generate the page for that specific user and return it? Something like that?

[jescalan]

Hi everyone! Just want to let you all know that this is something we are thinking about and discussing on the next team. I appreciate all the constructive conversation here and apologize for the slow response. Will get more updates in here as soon as I have them 😁

[jescalan]

@u382514 - it sounds like perhaps middleware might be a good way to solve a lot of the use cases you mention here! Have you given this a shot?

[willemmulder]

Passing data from GSP to GSSP is a valid request and is being considered in the implementation - thank you for the suggestion!

That's great news! Would make it much easier to do personalization and ensures we only make the necessary API calls in getServerSideProps based on the info that we get from getStaticProps. Thanks!

[tommy92]

Passing data from GSP to GSSP is a valid request and is being considered in the implementation - thank you for the suggestion!

@jescalan any update on this feature?

[willemmulder]

Yes I'm very curious as well 👍

[JumpForJoy]

Hi, @jescalan. Is there any issue created here in Github for this so we can follow its status and perhaps help somehow with pulling this feature out?

[eligundry]

One more use case here: You have an above the fold A/B test with content coming from your CMS. You have all the variants at build time, but assign the variant at runtime. In this way, you're fetching from the CMS only once but able to do the assignment an unlimited amount of times. In my mind, this would require forwarding the props from getStaticProps to getServerSideProps, but that might be a little too wild depending on Next's internals?

[jescalan]

A/B testing efficiently is something that we know is important for a lot of users, and we are working on a proposal for a way to do something very similar to what you have proposed here in your comment internally 😁

[allicanseenow]

Hopefully we can get an update for this.

Right now, by using automatic static optimization, I can't use authentication with my page, which is a big hindrance that forces me to ignore the feature for now.

[jescalan]

perform your auth logic client side for the 1% extra stuff

The problem here is security. There isn't really a way to do auth logic on the client side, because anything you want to run on the client side you need to ship the entire source code for. There must be a server-side implementation in order for authentication to actually do its job. I think this is what you're getting at with your response. Once you are running user-specific content that is behind authentication, static is not really a viable option anymore.

But really I think that's fine! Static is just what it is named: static. If your use case is dynamic, rendering content dynamically is the right choice, and is totally fine. Luckily, nextjs makes it super easy to render in either way in your apps, so you can make that choice on a per-page basis. That was one of the things that sold me on it in the first place 😁

[timfuhrmann]

@jescalan Is Vercel using middleware for auth redirects? - just wondering 😁 I think the last time I checked, redirects related to authentication happened client side within the header and user-specific content is also fetched client side, I assume by using serverless functions and finally the http only cookie?

We have used the same approach for many of our applications and honestly I don't wanna miss the performance that comes with static site generation anymore. I guess even if we could use both GSP and GSSP, we would probably still go for the approach I just described (or middleware), at least for the use cases we've had to this day.

[jescalan]

Currently vercel is not using middleware for auth redirects as far as I can see.

If you are running an app that is entirely behind auth, shipping an empty static page and fetching everything from the client is a fine approach, generally. You'll drop some performance, as its faster to render from the server than to send an empty page to the client, fetch data from the server, then render on the client. You also drop SEO/social share benefits since crawlers read the html and generally don't execute javascript, so they will read an empty page. But if a page is accessed only by logged in users, it's not going to be indexed by search engines or shared, and the performance difference is not likely to affect your metrics, since already registered and logged in users are not as likely to bounce from the site. Using this approach for any sort of public page, marketing materials, or anything that requires the best possible performance is when you might want to think twice about it, IMO. Hopefully this is helpful?

[timfuhrmann]

@jescalan Yes 100% agree! Just wanted to emphasize that in some scenarios you don't necessarily need GSSP or even a middleware to handle authentication redirects.

[jescalan]

Certainly true 👬

[zanewolf]

I also have a use case, one that doesn't involve authentication. I have a directory of static items (GSP) and these are sortable by category options at the top of the page. Clicking one of the options updates the state via useEffect and refilters the data yada yada. There is one main link to the directory and the default state is set to 'All', but I'd like to have specific links that only display the matching category of the data on load.

<Link href={{ pathname: '/directory', query: { category: directoryCategory }}} as: '/directory'>
<a>Click here for directory</a>
</Link>

From my understanding, the way to do it would be GSP accesses the directory items and GSSP would access the query param and set the category state on load. However, I'm new to next and still learning react in general, so if there's another way to accomplish this, I'm all ears.

[giovanni-caiazzo]

Hi all, sharing my solution:
I was in need of this feature too, because in my blog I needed to serve for each slug the statically generated page to normal users and a server-side preview page to writers that would display pages from the CMS that were not published yet using the same URL but with a special query parameter. I settled on using the Middleware nextJS service with the rewrite attribute. It is really handy because it shows content from a different nextJS url without changing the actual URL. So I made a different nextJS route that showed the same content but using getServerSideProps instead of getStaticProps and used the middleware to replace the static route with the dynamic route when necessary.
Hope this helps someone in need :)

[macdermott]

Hi @jescalan, is there any update on if/when this might be available?

[jescalan]

We have a big conference coming up at the end of this month - you should tune in 😉

[allicanseenow]

Eager 👀

[GMaiolo]

Nice teaser @jescalan

[allicanseenow]

Can this be achieved with the new data fetching pattern introduced in Next 13?

[leerob]

Update: We’re excited to announce Next.js 13, which includes the new app/ directory (beta) with support for nested layouts, colocation of data fetching, streaming, Server Components by default, and much more.

Inside the app/ directory, there is a powerful new way to fetch data with React’s use() hook and the extended Web fetch() API. This allows you to colocate data fetching directly inside components for the most flexibility, including inside layouts.

You can leave feedback here: #41745

[leerob]

Give these a read:

• https://beta.nextjs.org/docs/rendering/fundamentals
• https://beta.nextjs.org/docs/rendering/static-and-dynamic-rendering
• https://beta.nextjs.org/docs/data-fetching/fundamentals
• https://beta.nextjs.org/docs/data-fetching/fetching

export default async function Page() {
  const static = await fetch('https://...');
  const dynamic = await fetch('https://...', { cache: 'no-store' });

  return '...';
}

[willemmulder]

Thanks! Just to be sure, that would result in the Page() function to be run on every request, but it would run the first fetch() function only the first request, and then re-use the result on all subsequent requests, while the second fetch() function would be run on every request. Is that correct?

[leerob]

Correct, this page would be run on every request. The first fetch is automatically cached (you don't need to manually use cache()) during the build, not on the first request. This is similar to getStaticProps. The second fetch would run on every request, similar to getServerSideProps.

Note: ISR is also supported, still.

[leerob]

To be extra clear, this hasn't fulled landed yet. Right now, if you mix static/dynamic in the example above, the page will still be dynamic. But this is planned and something we're actively working on. I just wanted to share the vision where we're headed here as we move further forward in stability for the app directory.

[willemmulder]

Thanks, that would make things so much faster! :-)

Two small related questions:

1. How can we cache props that are not loaded using fetch(), for example DB results using prisma? does the cache() function help there? I hoped that would give us caching like fetch() for database queries, but from the docs it seems like that function provides memoization during a request, but not between requests. In other words, the cache does not persist between requests. Is that correct?

2. Does caching work on the edge? Is every cached fetch() call distributed to all edge nodes?

Thanks!

[leerob]

With the stable App Router in 13.4, static or dynamic data can be fetched, cached, and used together in the same route segments.

• https://nextjs.org/docs/app/building-your-application/data-fetching
• https://nextjs.org/docs/app/building-your-application/data-fetching/fetching
• https://nextjs.org/docs/app/building-your-application/data-fetching/caching

export default async function Page() {
  const static = await fetch('https://...');
  const dynamic = await fetch('https://...', { cache: 'no-store' });

  return '...';
}