Need to explain Docpad persistence

Question

I'm pretty confused about the architecture by which data is stored in Docpad. From blogs and forums that I recognized in memory (and / or outside of a directory), it is used for generated content. But one of Docpad’s selling points is “completely file-based.” From its sound, placing it on Heroku or any ephemeral file system does not seem logical. Can someone give an explanation / clarification?

Answer 1

DocPad is used as the next generation web architecture. This mindmap demonstrates why we call it this:

DocPad Architecture Vision http://d.pr/i/jmmZ+

The workflow looks like this:

• Importers bring data from any source, be it the local file system or tumblr or the mongo database.
• They are entered into the DocPad database in memory
• During generation, DocPad then displays what needs to be rendered and outputs static content to the out directory
• Dynamic documents (documents that are redrawn for each request) and dynamic capabilities (server extensions) can now use the database in memory and perform advanced cool things, such as downloading files, contact forms, search pages, any

In this sense, DocPad is the next generation web architecture that has the ability to generate a static site, as well as the dynamic capabilities of site generation. What separates DocPad from traditional web architectures is that traditional web architectures consider the content and patterns of individual creatures, where DocPad considers them to be the same and simply separated by their extension. Traditional web architectures are also dynamic by default, with static caching being used to create sites, and not vice versa. Static by default.

Due to this load, everything in the situation with the database in memory, we suffer from growing performance problems during generation and post-generation. The discussion is here. However, there is nothing that cannot be fixed with enough time and resources. Regardless, DocPad will still be faster than your traditional web architecture due to its static nature (faster requests) as well as its asynchronous nature (faster generations).

In terms of how you will handle file downloads:

• If you are building a static website with DocPad, you will have a backend API server in another place that you would also upload and upload data to DocPad as a single-page application style.

• If you are building a dynamic website with DocPad, you will host DocPad on a server such as Heroku and expand the server to handle uploading the file to a destination such as Amazon S3, Dropbox or MongoDB or the like. Then you can open the file via templateData as a link or insert a file into the DocPad database in memory as a file. Which one did you choose, do you just want to link to the download or consider it as a first-class citizen in the DocPad universe (it gets its own URL and page).

For dynamic sites, I would say that I really use a static site + one-page approach. You get benefits such as responsive design, offline support, very fast UX, which, without doing it this way, struggles a bit with the dynamic approach to the site, no matter what kind of web architecture you build it.

Answer 2

Well, I can't tell Benjamin's excellent explanation, but if you want a TL; DR explanation: DR:

docpad is used to create STATIC websites, a-la github pages, or the old websites of the 1990s. You can write your pages anywhere (Jade, eco, coffeescript, etc.), and it will compile the pages and output HTML files. Think of it as a once-server-forever compilation.

On the other hand, if you want to use Dynamic Content on your site, you want to use Nodejs to pull dynamic data from other sites or create them on the fly.

As for your concern with the Heroku ephemeral file system (I don’t know exactly how this works), you can use Amazon S3 for storage. Check it out