Hook into the build system for custom processing steps.

[mainrs]

Most of my web pages display static data that rarely changes, if ever. Right now I simply query the database and use a template to render the data.

I was wondering if there would be a possibility to hook into the build system and write code to generate these web pages ahead of time. That way I would not have to render them using a template, but can serve the HTML code directly.

Is this currently possible?

For why I keep the data in a database and not use a static site generator: some routes are dynamic and rely on the relationships within the database to correctly link and display the data.

Thanks!

[kaplanelad]

@mainrs, I just want to make sure I understand your question correctly.

Are you asking if you can serve static HTML without using templating?

[mainrs]

Are you asking if it's possible to serve static HTML files without using templating?

That can already be done by reading the file at compile-time and returning it as a String in the response. If I remember correctly, Strings implement IntoResponse.

Let me give you an overview of my use case. My application is related to Minecraft. The database stores data about all blocks, including properties like name, texture, transparency, hardness, light emission, and more. Each block is assigned a unique PID, defined as a UUID.

Currently, I can access a block's data by visiting /blocks/<uuid>. The controller takes the UUID from the path, queries the database for the corresponding block by matching the PID, and generates a templated data context with the block's properties. This context is then passed to a template, which fills in the placeholders.

However, since the block data rarely changes, I thought, "What if I pre-render the block pages?" I could create static HTML files for all blocks, stored under assets/static/blocks/.html. Then, the controller would simply read the appropriate file and return it, bypassing templating. Another option would be to build a perfect hash table at compile-time using pdf, which reads the file contents. Since the data isn't large, this would eliminate filesystem access and allow the controller to perform a simple O(1) lookup.

Currently, I manually run a custom script to generate these static pages. But I was wondering if there’s a mechanism I’m missing that allows me to integrate this process into the loco build system. loco knows when to recompile migrations, and the only time I’d need to regenerate these static HTML files is if the migration package changes.

One possibility is embedding the file generation into a migration. However, I’m concerned this would create the static HTML files during production, which I want to avoid, especially since the application is deployed via Docker.

[kaplanelad]

Thanks for sharing your use case.
You’re right that IntoResponse can handle returning a String, and you could leverage format::html from the Loco framework (see here) to return pre-rendered HTML content directly.

For your scenario with pre-rendering Minecraft block data into static HTML files:

Serving Pre-Rendered Files with Local Storage:
You can use Loco’s local storage to read files from the filesystem, like assets/static/blocks/<uuid>.html. Your controller could fetch the file content and return it, skipping the templating step entirely.
To boost performance and cut down on filesystem reads, you could add an in-memory cache by after reading the file, store the content in the in memory cache.

Then, if the file does not exist, you can generate and store it in the file system for the next request (with the storage provider).