A static website wants to provide an editing background, where is the difference between external content management and self-built?

A static website wants to provide an editing backend, what are the differences between the three approaches - the difference is not in 'whether there is an interface', but in whether you can constrain the content structure, whether you can move data in bulk, and whether you need to maintain a resident service layer for the backend. The external approach is priced per site or seat, for example, starting at $12 per month for a site-based package, or $55 per month for a product; the self-built approach puts the editor and content model in the same system, at the cost of deploying and updating the system itself.

The characteristics of each of the three approaches

The first is an external third-party content management. The content still exists in the repository or static directory, and the third party only provides an editing interface and writing channel, with the construction process unchanged. Among the several types of product forms visible on the day, there are both free open-source management ends that have been evaluated as 'already showing age' and hosted services that are available for use as soon as they are purchased. It is suitable for teams with low change frequency, few editors, and those who can accept third-party interfaces.

The second is to run a management program on the Node side again. This kind of solution will introduce additional runtime dependencies in static projects, such as an editing layer that 'puts Node.js into your project'. For sites that used to only do building, this is equivalent to an additional set of dependencies to maintain and a resident process to run.

The third is a system with a built-in backend. Editing, content model, and publishing status are all in the same server-side service, and building a website is no longer a necessary step.

Where is the poor experience on the editing side

The two most important things that editors care about daily are whether they can preview and how long it takes for changes to go live. In the scheme of external add-ons and management, after the editor saves, it usually triggers a build, and the page is updated on the site, which makes 'correcting a typo' into a waiting event. The editor's save in the self-built system directly affects the online data,配合 with draft and preview states, editors can judge the effect of the changes themselves without understanding the build.

The second difference is in the granularity of permissions. The users and roles in the external scheme are mostly controlled by their own system, with limited granularity; in self-built systems, user groups and access permissions can be divided according to business, who can see what content, who can change the template, can all be expressed in the same set of permission models.

Operating environment requirements

The need for a resident service is the main cost of self-built routes. However, resident does not mean consuming resources: A server-side process developed in Go language can reduce memory usage by about 80% compared to traditional PHP content systems. This figure comes from the project description and is a level judgment rather than an accurate multiple. On the other hand, the external solution saves the resident process but shifts the cost to construction time and third-party account management; the Node side needs to maintain both construction and runtime dependencies.

The method of judgment is the number of people and the frequency of change: sites with only a few changes a day and fewer than three or five editors have a lower total cost for the plug-in solution; sites that publish multiple times a day and require a review process and variable content structure are easier to spread the cost with a self-built system on a permanent layer.

Content structure and batch import

The content structure determines where the editor can make changes. In the self-built system, the content model and custom fields are first-class capabilities, adding a field or changing a content type can all be completed on the same backend; the structure definition of the plug-in solution is scattered in the configuration files of static engineering, and editors cannot make changes, ultimately still requiring development intervention.

Moving and batch operations are also a dividing line. There are already hundreds of articles that need to be transferred to the site, and it needs to be checked whether it supports compressed package or table form for batch import, whether it can be duplicated by title before writing. If there is only a single entry interface, the human cost during the migration period will far exceed expectations, which is also the actual reason why many static sites abandon the plug-in scheme halfway.

Common questions

We already have a Git workflow, do we need a backend?See if the editor uses branches and commits. If the editor does not touch the code, you need an interface that can write and trigger building, the plug-in scheme can solve it; but when the content structure changes, you need to change the configuration, and it is still more convenient to use the built-in backend in the long run.

Can the plug-in scheme be changed later?Yes, as long as the content is still saved as a text file. The assessment focuses on whether the export format is parseable and whether the paths of historical images and attachments are taken away as well.

How heavy is the upgrade burden of the self-built system?It is mainly the update of the server process and database. When choosing the deployment method, think about the fallback path, a complete backup plus a switchable image, usually can control the upgrade risk within an acceptable range.