(Corporate CMS) Jun 2025 — Dec 2025 · Webbrains Technologies
One system for every page and product, with every edit checked and recorded.
A content system for a corporate website and product catalogue. Every edit is checked and recorded, and the whole system is packaged to run the same way on any server.
(01) In numbers
From first schema to handover
Validation and audit, ahead of every handler
The same image locally and in production
(02) Under the hood
01 · EDITOR
Someone changes a page. Before any of it reaches the database, the same questions get asked that every other content type asks.
02 · VALIDATE
Payload shape, required fields and types are settled in middleware. A controller that runs has already been handed something it can trust.
03 · AUTHORISE
Who is allowed to edit this type, in this section. The check sits in front of the route rather than inside it.
04 · AUDIT
Who changed what, and when — written by the shared layer, so no content type has to remember to do it.
05 · SERVICE
The part that is actually specific to this content type. By this point it is only the part that is specific.
06 · DATA
Mongoose models per content type, sharing the same base fields and the same audit shape.
07 · SHIP
The service, its database and its proxy described in one file. What runs on a laptop is what runs on the server.
(03) The story
01 — The Problem
A corporate CMS grows content types faster than it grows anything else. Each new one needs its payload validated, its editor authorised and its change recorded — and written per type, those become dozens of nearly identical blocks that drift apart quietly.
02 — What I Built
Validation and audit were pulled out into middleware that every route mounts. A content module is then only the logic that makes it different, and the whole service is described in Compose so the environment stops being a variable.
03 — What Changed
The rules arrive with the mounting rather than with the author's memory. And because the container is the unit of delivery, works-on-my-machine stopped being a category of bug.
(04) Architecture
01
The admin surface the content team works in.
02
Nginx and PM2 in front of the Node service, with SSL.
03
Validation and audit: the two layers every route shares.
04
Express modules, one per content type, mounted behind the shared layers.
05
Mongoose models with a common base and a common audit shape.
06
Docker Compose describing the service, the database and the proxy together.
(05) Decisions
Validation and audit are things every mutation needs, so they are mounted rather than called. Did this route remember? becomes a structural question instead of a review comment.
Content types differ in their fields, not in how they are created, changed and recorded. Sharing that base is what makes a new type cheap to add.
Compose describes the service together with its database and its proxy. The environment stops being something that has to be rebuilt by hand and remembered correctly.
(06) Built with
Written once, mounted everywhere, shipped as an image.
For the technically curiousReusable audit and validation middleware, containerised end to end. A corporate content platform with many content types, each one needing the same things before it writes: a validated payload, a permission that holds, and a record of who changed what. Those became two middleware layers every route shares, and the whole service runs in containers from a laptop through to production.
Node.jsExpressMongoDBMongooseReactDockerComposeNginxPM2JWTWinston