How should static site generators and dynamic CMS be divided, where is the boundary of the hybrid architecture?
How should static site generators and dynamic CMS be divided, where is the boundary of a mixed architecture? The boundary is not determined by function, but by whether 'who changes the content, how much is changed, and whether permissions are needed'. A public comparison clearly lists the differences: Hugo uses local Markdown and does not require a database, while systems like Halo support editing in the browser, with the server cost of running it about fifty to two hundred yuan per month. The former saves on the running environment, while the latter buys collaboration and dynamic capabilities.
These two types of tools do not solve the same problem.
The way static generators work is to render all pages into files during the build period, with the output directly returned by the web server. The benefits are very tangible: there are no runtime dependencies, no concerns about the database being slowed down, and the hosting costs are reduced to a very low level. The cost is that 'changing a character requires a rebuild', as well as the lack of built-in account, permission, and form processing.
Dynamic CMS reversed: content exists in the database, it is rendered only when a request comes, therefore it naturally supports collaboration among multiple people, role-based permissions, and interactions such as comments and messages. It also supports a structured content model with customizable fields. The cost is that a running environment must be constantly resident, and someone needs to apply patches and backups.
How to draw the boundary
Dividing by content attributes is more stable than dividing by pages.
| Content type | Change frequency | Do you need permissions | Suggest placing |
|---|---|---|---|
| Brand promotion page, event landing page | Low | Not required | Static side |
| Technical documents and help center | in | Need editing分工 | Dynamic side |
| Product library and parameterized content | High | Need to be reviewed | Dynamic side |
| Messages, comments, forms | Continuously produced | Need anti-spam | Dynamic side |
| Archived old articles | No longer changed | Not required | Static side |
The last two types are often ignored: after the staticization of archived content, the database pressure and backup volume of the main station will decrease significantly.
Three types of cuts
The first is dynamic on the main station and static on the edge. The corporate website runs CMS, and the activity pages, special pages, and archived pages are exported as static files and placed in independent domains or subdirectories. This method has the least operation and maintenance burden and is suitable for most small and medium-sized enterprises.
The second option is to fetch data from CMS during the build period. The content is still maintained and reviewed in CMS, and a build is triggered by the publishing action, outputting the column into a static file. It preserves the editing experience and permissions, as well as the loading advantages of static pages, at the cost of maintaining the build chain.
The third option is to run two sites in parallel, where each system manages a portion of the content and synchronizes necessary data through interfaces. This approach is only cost-effective when the team and content scale are both very large, and small teams usually get bogged down by the synchronization logic.
The dynamic side should make the URL look clean.
The most easily overlooked in the hybrid architecture is the consistency of the address: the static side naturally has clean short addresses, and if the dynamic side exposes query parameters, the URL style on both sides will split, and the jump and collection processing will become complex.
AnQiCMS's pseudo-static rule management supports custom pseudo-static URLs, which can output dynamic pages into addresses with the same style as the static side, making the hybrid architecture look like a single site from the outside. The custom content model then takes on the structured side: product parameters, case numbers and such fields are maintained on the dynamic site, and can be used as needed when statically exported.
The operation layer still needs to prepare two things. Backup and recovery need to cover data and static files, especially in a hybrid architecture, it is easy to only back up half of them; the deployment method should be selected according to the team's ability, AnQiCMS provides one-click deployment with Baota panel, aaPanel, LNMP command deployment and Docker image, default listening on port 8001, the static side can continue to be placed on the original Web server or object storage, and no additional runtime environment needs to be added for it.
Common questions
Question: How to submit the form on the static side?Answer: Entrust it to the dynamic side or a third-party form service, do not hard-code form processing into the build process; when submitting data that needs to be stored in the database, the dynamic side is naturally the more suitable position.
Question: Will there be discrepancies between the two sides?Answer: Yes, this is the main cost of the third method. The way to avoid it is to specify a single data source: content is only edited in CMS, the static side is always produced by the build, and manual modification of static files is prohibited.
Question: What should I do if I need additional permissions with the site fully static?Answer: There is no need to migrate as a whole. First, add a dynamic sub-site to accommodate collaboration and interaction content, use pseudo-static and redirection to unify the address styles on both sides, and then gradually move the high-frequency change columns over.