Full static generated mode

[TheAlexLichter]

Current state

Nuxt's Static Site Generator (nuxt generate) is growing! I love the static mode when it comes to portfolio pages (or generally, pages that don't include a lot of dynamic data).

Problem

Usually, you use statically generated pages together with a Headless CMS or another external API.

Currently, you can generate the HTML (with static + universal mode) but asyncData calls are still made during client-side navigation, which means that an external API will likely be called on such a static page.

While it's worth here and there to make these calls even after static generation, it's absolutely not needed (from my POV) for the majority of the pages. Instead, the author/developer could simply issue another build (eg. through Netlify) to update the content.

Also you might encounter different content as asyncData is not called on the entry route of you static app. (Going from /b to /a can lead to different content than directly accessing /a)

Proposal

As announced by @atinux on Vue Toronto (see his talk at 26:18), I want to propose the full static generation option for nuxt generate.

Instead of relying on the API calls, we should inline the response of the asyncData method(s) inside a .json file (per page) when the generate.fullStatic flag is enabled in the nuxt.config.js (the flag name is debatable). Then we can use the .json file as data source without issues.

Related issues

nuxt/nuxt#4607

3rd party modules that apply this approach

https://github.com/DreaMinder/nuxt-payload-extractor
https://github.com/stursby/nuxt-static/

[YamenSharaf]

As someone who's working to create a fully static site, this has been an issue for me as it looks like there's no way currently to have a fully static site with a headless CMS.
Nuxt has a lot of tools that help with that, but not quite in a way that ties them together to create something as fast as a static site should be.

These are the options I've stumbled across so far:

Relying on asyncData in page components

Pros

• This is the natural /encouraged approach by Nuxt docs
• Each page pulls in its own static content. Refreshing the page yeilds static content without extra AJAX requests.

Cons

• When navigating through nuxt-link to pages with async-data function defined, an AJAX call is fired before each page navigation to, again, load the data that is already statically on the page in a needless fashion. I'm no expert, but I guess that entails also shipping the vue engine to bind data coming from the server (also needlessly).

Relying on payload

Pros

• Nothing I can think of really, since the earlier approach seemed to work fine for pulling data for individual pages.

Cons

• More complex to implement.
• When navigating through nuxt-link, payload property is always undefined, which means I would have to have an asyncData method that would fire anyway on each page navigation.

Utilizing the vuex store and nuxtServerInit to get needed data

Pros

• No AJAX call is triggered when pulling data from the store (seems fair), even when navigating with nuxt-link.

Cons

• Store is basically global and not confined, which means that pulling data upfront. eg, posts, will cause them to load on each page even if not needed, but you do get faster navigation afterward.

Conclusion

I would have had rather be a straightforward way to pull data from an API without the overhead of extra AJAX requests or loading unneeded data.

[pi0]

Nice writeup @manniL.

For more specific terminology let's call this behavior/mode static and the offline data source files cache data.

Adding some more important notes:

• We should consider we have fetch, asyncData, nuxtServerInit and SSR plugins that all should be addressed also can cause side effects like triggering store dispatches that they can also fetch/process data.
• Cache items have no one-to-one relation with pages or route entries. Wildcard routes and query parameters require different responses. (edited: this is a rare case as we generate one HTML per each)

Regarding implementation and future opportunities I can think of 3 ways:

1. Memorize asyncData

This way, during generating we can spy result of asyncData during SSR generate and store it somewhere like .nuxt/dist/cache. Then by modification of asyncData implementation for client-side instead of the original method we import corresponding cache item. This also addresses the need for duplicate HTTP requests.

Pros

Most straight-forward approach.

Cons

We can't guarantee everything is cached. fetch and store may have their own logic.

2. Cache window.__NUXT__

This way, during generate we cache nuxt states into .json files and like method (1), change the behavior of client-side for fetch and asyncData

Pros

Straight-forward and covers store state too.

Cons

• The possibility of breaking change for exciting projects.
• How to handle non pojos?

3. Cache network requests

This way was the one that me and @atinux talking about it almost one year ago for static mode. Instead of internal nuxt hacks, we can find a way to spy on network requests and statically cache them somewhere like .nuxt/dist/cache/[hash].json and instead of doing actual requests we can import json chunks.

Cons

• Spy part is delegated to official nuxt modules. (However, if changes required to the core, we make them)

Pros

• Updating API cache is independent of nuxt generate. We can update it without rebuilds
• We have full control over each ajax/http call to be cached. Not caching a black-box
• No internal hacks and breaking changes
• Transparent caching means making it optional without the need to changes of fetch/asyncData and store actions for offline support
• More service-worker spec friendly for caching and PWA like approach.
• Works with other modes (@manniL)

[pi0]

After talking with @atinux, both (2) and (3) options seem good approaches. Most of the static generated websites do not need complex logic and simply storing NUXT object will be enough but also network level caching has it's own benefits too.

The suggested approach is introducing a new $cache API to the nuxt core which is responsible for storing and loading cache entries. This API may be used directly by users or module like axios. The cache layer may leverage a cache adapter too.

I do believe we can include a really basic default implementation to the core. Adapters should be probably different for server and client (cache.client.js and cache.server.js. Like nuxt/nuxt#4574 which made by Sebastien for nuxt-link)

For page level caching during generating full static version, we can add a cache property to the pages or global config (Like transition) that can enable/customize page level caching and probably globally enabled when using nuxt generate --full-static. We can then store ssrContext.nuxt.data to a JSON file that will be loaded instead of calling asyncData and fetch on the client side. This should be also clearly documented that those functions are no longer being called on full static mode.

For changing client-side behavior we can use lodash template to replace default asyncData/fetch calls with $cache.get($route) calls (vue-app/template/client.js)
For client-side support we can add logics to read cache option from page or global and use $cache.get($route) instead of calling functions. (vue-app/template/client.js)

[atinux]

I strongly validate @pi0 comment.

This caching system could be used by other modules and inside services too in the future.

Nuxt is build on modules, we simply need to have @nuxt/cache now.

The thing I want to work on is to give more possibilities to modules to customize the Nuxt logic of client-side. This could be done by extending defaults components, or having some hooks system. So Nuxt plugins could also interact more the client & server logic of the default Nuxt logic (middleware, async data, transitions, store, etc)

[TheAlexLichter]

One aspect we shouldn't forget: Making a page "full static" by actually removing the API calls from the code also means that the underlying API is harder to attack (via DDoS, exploits, ...) as a possible attacker doesn't know where the target API lives.

Of course, Security through Obscurity is no sophisticated security concept at all.

[pimlie]

Could we take this rfc maybe a step further and also include an option to build an all inclusive, single (static) html file? There are times this would be useful, e.g. when you create a demo of something so you can just email a single html file to a client or upload multiple demos to your website without the need for subfolders etc. But also an Electron application could benefit from this when all html/js/cs is loaded at application start-up, or a better example if you want to put a single html file on a usb-stick to hand-out as a promotion.

E.g. in the past I've used a grunt script to achieve this (albeit for a non-Nuxt project). As combining all the css/js/font files resulted in a single 1.3MB html file, I embedded all files zipped & then base64 encoded which reduced the file size to 550KB. (Of course the unzip javascript code and the js for the loading dialog was not zipped).

[pi0]

@pimlie Nice idea. We may use MHTML format to encapsulate all resources of each page. And it is easier to compress.

[pimlie]

Although mhtml would in theory be better, it lacks the full support which plain html file has (eg Firefox doesnt support it by default). But if all the hooks are in place, we could choose to create modules to generate both mhtml as html.

[atinux]

Indeed, this could be made with the help of a module @pimlie, this module could:

• Overwrite all webpack file/url loader to force include as data64
• Find any url that point to a static file and include it's base64
• Remove code-splitting to have only one huge JS file?

Also, with 2.4, modules can create sub commands 🚀

[DreaMinder]

I've made a module for this purpose, didn't know that a simillar one already exists.
Its very simple, but requires custom code in asyncData like payload mechanism does.
Repo: https://github.com/DreaMinder/nuxt-payload-extractor
Working demo: https://dreaminder.pro/ru/blog/nuxt-vs-vue-spa-battle (just a sketch of my blog)
Maybe you'll find usefull some ideas I used.

[TheAlexLichter]

Another problem that comes to my mind is queryString. But something like /articles?page=2 won't work properly when you have no server behind it.

We should still think about that