Live Content mode in production?

[shareable-vision]

My goal is to deliver dynamic content that can be edited in production by providing site-owners some kind of an editing interface . . for example: Github or Gitlab or NextCloud, which has the added benefit of optionally syncing to the owner's desktop environment, where they can freely edit content from a very normal-looking directory of nested markdown content and assets and modified with any editor that they are comfortable with.

Writing is a very intimate, creative process. Similarly to how some (less tech savvy) folks are uncomfortable with tools like Github, those same individuals may not feel as comfortable and productive using an online editing interface at all. If we want to make the web authorship work for anyone, if we care about tending toward the "democratization" of publishing, then we need to bring the tools as close to the author as possible without exposing them to the technical complexity. I think this is a cultural and not merely a technical work, however we have to see where technological decisions create resistance to human creativity, which aught to be the actual goal.

I would love to leverage the Nuxt Content module. The way it parses directory paths to provide route navigation and querying, the way it renders MDC content is awesome.

However in issue #1933, @atinux states that:

Prod is hard since it is cached and the files are directly linked to the filesystem . . . We do have https://nuxt.studio/ that will let you live-edit Nuxt Content websites in production I don't know if you saw it?

What would it take to provide a production-ready mode, where content and assets are not necessarily bound to the filesystem?

I do not want to have the site re-built, when markdown content and assets change —I want to deliver dynamic content on-demand. Re-building the application introduces latency and non-trivial "devOps" that could threaten the stability of the application —what happens when site owner writes errors into markdown content that will not parse? These errors can easily break the build-step, then the site would be either down, or would be stuck with a dead build that no one can understand the cause of. Essentially it introduces the consumer/owner of the site to development process issues that they have no business in the middle of. And it draws the developer into the added complexity of somehow managing parallelization of the application with tools like PM2, of somehow reporting the root cause of the failure back to the running application . . and, of course, this introduces further complexity of pulling client data out of application memory and towards solutions like Redis.

Why not just handle dynamic content in the running application? If the application were not re-built when content changes but was actually designed to safely accommodate the dynamic content and report errors back to the consumer in a clear way, so they can resolve the issue and resubmit.

Nuxt Studio sounds super cool. However it's not a one-size-fits-all situation . .

I've written something very similar to Nuxt Content (in another framework) from scratch, which parses a content directory and generates a routes and serves the content directly, but I really appreciate how Nuxt Content uses Unstorage to decouple from the specific source and how it renders MDC.

Is it in the realm of possibility that the Nuxt Content module might want to support a Live Content production mode? I am absolutely willing to help.

[shareable-vision]

It looks like "live" content was allowed in production in v1 via the useCache option.

Is there a technical reason this feature was deprecated?

It looks really simple to add this line to the module.ts definition:

const useCache = Boolean(!nuxt.options.dev && options.useCache)

And using cacheContent in place of !nuxt.options.dev throughout the module definition to preserve the behavior of parsing content on-demand, when useCache is configured as false —let it be true by default.

Although prerendering "improves app startup time", this has the effect of making the app "unaware of any content changes," as per Nuxt Content docs v1.

[shareable-vision]

PR #2212

[kogratte]

For the record, I've been working recently for my company on a solution which sounds exactly the one you have.
Without delivering the details, I've been able to achieve exactly what you need, by building a custom development image which is a "ready to go" image.
One the project is initialized, there is nothing more to do than adding content. A live server is hosting the result using docker. Once the user is satisfied of the changes he made, he just need to run make generate in order to generate a full static website ready to use.

The only remaining part is to upload them to any static provider, which can be done in a single command leveraging on Surge.sh