Architecture Design of Hugo #
Hugo’s architecture idea is easy to understand. It is mainly divided into three major blocks: configuration module, site module and dependency module.
Configuration Module
The first thing Hugo parses is the configuration file config.toml of the user project. Initiated by configLoader, the configuration file is read from the hard disk and stored as a key-value pair object after parsing.
configLoader mainly needs to complete three things:
- Load the user project configuration file to understand the user’s custom requirements.
- Complete the default configuration
Defaults Config, to ensure the normal operation of other modules.
- Generate module configuration information, starting from the user project, using the user project as the first module -
project module, and in our example there is a second module, that is the theme module mytheme.
There are dependencies between modules and there is only one Owner Owner. The project module project module is special, because it is the initial module, so it does not belong to any other modules.
type Module interface {
...
// Owner In the dependency tree, this is the first
// module that defines this module as a dependency.
Owner() Module
...
}
After all the information is collected, the config.Provider service will be provided externally: it can be queried and configuration items can be updated.
HugoSites Module
This is the core module of building a site, which is equivalent to the aggregate root in DDD. It organizes all the information needed to build a site internally and provides site building services externally.
The initialization of HugoSites depends on DepsCfg and Site, yes, there are two sites. The relationship between HugoSites and Site is one-to-many, and the relationship between Site and Language is one-to-one, so a multilingual site will create a site for each language, which together form HugoSites.
Language items are created by DepsCfg, but will be stored in config.Provider, so they are marked in light yellow. The initialization of DepsCfg depends on Fs and config.Provider. Fs records the source file address and release address. The source files come from the user project, which is the actual hard disk file system. The publishing address is obtained from config.Provider, and the default is the public folder. It will check whether it already exists here, and create it actively if not. Finally, synchronize the newly created information such as workingDir back to config.Provider.
As can be seen, their dependencies are HugoSites <- Site <- Language <- DepsCfg <- Fs.
Deps Module
Hugo refers to all the services and objects needed to build a site as dependencies, and puts them all in Deps.
In the process of building dependencies, TemplateProvider that provides templates will be generated; Clear input and output media type MediaType; and output format OutputFormats; will be updated to config.Provider.
It will also be prepared for collecting site content, and there will be a Page Collection to help collect. The publishing service that needs to be used when finally publishing the site is Publisher. These will be updated to Site.
At the same time, it is also necessary to manage resources in a unified manner with clear specifications, which can ensure the convenience of use and conform to the principle of single responsibility in the principle of oriented design. Contains Path Spec that provides a unified standard file structure service; and a Resources Spec with all media type and output format information; and a Content Spec that provides services for Content information; Plus Source Spec to help define resource policies, such as filtering functions.
With the help of Deps, all the information needed to build the site, such as raw materials, rules, and output formats, etc., are prepared.
If you don’t speak Golang then don’t try to adjust Hugo to your needs. If you want to create a static website, then use it. It’s perfect for it. And speedy.