Good systems start with fewer moving parts
Before adding another service, it helps to ask what the system actually needs to do. A case for making the architecture smaller first.
In this entry
There is a point in many projects when the architecture starts answering questions that nobody has asked. A queue appears before there is a backlog. A database arrives before there is anything that needs to change at request time.
This is an example essay about a useful starting question: what is the smallest system that can do this job well? It is not a report of a production experiment or a claim about measured performance.
Start with the job
A journal needs to make writing available to readers. If one person writes the entries and each entry changes only when that person edits it, the system does not necessarily need to assemble the page for every visitor.
It can do that work once, during a build, and serve the resulting file many times.
That changes the shape of the project. Authentication, persistence, and an editing interface may still be valuable in other contexts. For this context, the simplest publishing workflow can be a folder of text files and images.
Move work to the right moment
Consider the distinction between two kinds of work:
| Work | A useful time to do it |
|---|---|
| Convert Markdown into HTML | When the article is published |
| Resize an article image | During the build |
| Create a list of related entries | During the build |
| Save a reader’s private account settings | At request time, if the product needs accounts |
The point is not that one approach is universally better. It is that each capability should have a reason to exist.
// A publishing workflow can be a sequence of explicit steps.
const article = readMarkdown(sourceFile);
const validated = validateArticle(article);
const page = renderArticle(validated);
await writeStaticFile(page);The code above is illustrative pseudocode. It describes the sequence, rather than an API you can import.
Keep the trade-offs visible
Static publishing means a content change requires a new build. That can be a good fit for a journal, and a poor fit for a shared document with live collaboration.
Similarly, removing a public editing interface reduces the number of application components to maintain. It does not remove the need to protect the repository, review dependencies, and secure the hosting account.
Simplicity is useful when it makes the responsibilities easier to see.
Leave room for the next real requirement
The next step should follow an observed need. If readers need to search hundreds of articles, a static search index can be added. If several editors need to collaborate from their phones, a different publishing interface may become worthwhile.
Until then, a smaller system gives its author fewer things to operate and a clearer place to focus: the writing itself.