Use Nextjs handler in API routes to be able to use renderToHTML

[janus-reith]

There are some usecases where pages need to display up to date data, which doesn't exist during the build step and can't be fetched on clientside, e.g. product pages in a Catalog which needs a good SEO.

As I have not found a way yet to render static pages on demand or something smilar to cover this usecase, it seems like using Initial props / getServerProps together with some page cache would still be the most feasible solution.

Using a Cache for SSR pages currently requires using a custom Server.
The example implementation uses the cacheable-response package and then calls renderToHTML of the nextjs app handler.

In my API route I only have access to res and req. Would it be possible to make renderToHTML, or maybe even other next handler functionality available over these API routes?

BTW: I would also appreciate other suggestions on how to solve the underlying issue described above :)

[timneutkens]

As I have not found a way yet to render static pages on demand or something smilar to cover this usecase

The case you're describing is already covered by getStaticProps:
Have a look at https://notion-blog.now.sh/
https://github.com/ijjk/notion-blog

However it's not documented in the RFC yet, will be a separate rfc.

[janus-reith]

@jasonbahl To give some context, back when I asked the question initially, there was getInitialProps which would run on the server (and client) for each request, thereby opting pages out from static generation, each page would be rendered per request on the server, and there was some discussion revolving around a new getServerProps.

The new methods for static site generation that would superseed getInitialProps where just about to be introduced:
https://nextjs.org/blog/next-9-3 (Released shortly after in March).
They were already available behind an unstable flag: getStaticProps( + getStaticPaths in addition to that for paths with dynamic segments ) to create static pages, and getServerSideProps for Server-side renders per request (Which I believe was called getServerProps before and was there a bit earlier than getStaticProps but Im not not entirely sure about the history of that one anymore ).

getServerSideProps would be closer to the earlier getInitialProps, but contrary to getInitialProps which was isomorphic and ran both on client and server (I believe based on wether a page transition happened on client side routing or server ), getServerSideProps would always run on the server, and for client-site route transitions just return the results as json, which IMHO was a great relief and made it way simpler to use than getInitialProps.

Shortly after revalidate was introduced (which was mentioned by Tim above), which could be returned in getStaticProps with an amount of seconds after which to re-run the data fetching logic defined in getStaticProps to render a new static page with that information. These are not scheduled with some background worker, but creating the new page is triggered as a side effect while the stale page Is served. Meaning that if you set revalidate: 60 and are the first user to visit the page after 120 seconds, you would still get the old page, but the next visitor might get the new one (if rebuilding it finished in the meantime). These pages are cached on the filesystem and additionally the value is also returned as s-maxage cache header, so further requests can just be served from a CDN if put it in front of it. (Or when using Vercel which has the CDN built in).

Usually, static pages would be created at build time, which might work for /index but not really for /blog/some-not-known-page as that doesn't exist yet, or simply you have too many paths you don't want to all be generated during build time each time you make a change.
So that's what is referred to as Incremental Static Regeneration, meaning that you could have dynamic paths which are requested at runtime and after being requested, become static aswell. (BTW that's what Im using with you WPGraphql plugin :) ).

The docs for this are here: https://nextjs.org/docs/basic-features/data-fetching

As of now, there is AFAIK no way to revalidate pages on demand using getStaticProps, only the time-based stale approach described above. (Happy to be corrected on that).

What you could do is:

A. Combine that with some query running on the client to check if data changed in the meantime(maybe calculate and pass a hash to avoid fetching the whole data) although that certainly results in more requests overall from different clients than necessary, and depending how you handle outdated data, might result in flashing content. Still mentioning it as it was fine for some use cases I had.

B. Don't use getStaticProps and instead combine getServerSideProps with your own CDN in front of it and make sure you return proper cache headers. In contrast to getStaticProps you wouldn't have that additional layer that the static file is served right from disk, but ideally these requests would hit nextjs just once anyway.
To revalidate a page, you would just need to invalidate that path on your CDN to trigger regeneration.

C. ...? (Curious about alternatives)

(V). In case of Vercel, have no control over CDN Cache Invalidation, but use their web hook feature to trigger a redeployment which would also prune the cache, although that might often not be a feasible option.
As I wonder why cache invalidation is not possible, I wonder if the explanation might be the same why there is no on-demand regeneration of static pages yet, that maybe it's simply too expensive to cover in the really great pricing they offer (But I really don't want to make any false statements here, I have no idea about the background of this and also found no details regarding that so far, just curious).

[jasonbahl]

Thanks @janus-reith! Lots of good info here. 🙏

[simoncarbajal]

Is it possible to manually revalidate on demand? so for example, immediately after updating some content?
That would be even more efficient than the current revalidate: seconds option

[stigkj]

@simoncarbajal no, that is not possible now.

[lstellway]

Here's another discussion discussing manually invalidating the cache:
#22384

I understand this is not currently possible, but is there currently any consideration / discussion about creating an API to manage the cache?
If so, would it be possible to provide a reference?

Thank you.