A reference
architecture
Four parts, each one a role. This stack covers most of what a small team will build.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
Once the stack is settled, every project after it starts faster.
Every new project can be an argument about frameworks, databases and hosting. The argument lands in the same place each time.
A default stack ends the argument. The parts are known to work together, the failure modes are familiar, and anyone who has used it before can read the next project. A common stack is also the best documented. Documentation is what an AI writing the code draws on.
A settled stack is also what a technical requirements document points at. Writing one for a new project becomes a page rather than a chapter.
A development framework is both halves of the application in one codebase.
The pages people see and the code that runs on the server live in the same project. A page can call a function that runs on the server without a separate service in between.
For a small team this removes a whole category of work. There is one repository, one deploy, and one set of dependencies rather than two of each.
A hosted database is a resource that nobody on the team operates.
The engine underneath is a standard one, so the queries are ordinary queries and the data can be moved somewhere else later.
A machine. Patches, backups and failover belong to the provider.
A hosted server is the platform that runs the application and answers the requests.
There is no machine to provision and nothing to install. The project is connected once. From then on the platform builds the code and runs it.
Capacity moves with traffic. A quiet week and a busy one need no action from anyone.
A push to the main branch becomes a deployment.
Version control holds every version of the project. A shared copy sits with a hosting service, which is what the whole team works against. The platform watches that copy.
Commit, push, and the platform builds the project and puts it live. Nobody copies files onto a server. There is no separate release step to forget.
What is in the main branch is what customers are using, so access to the repository is access to production.
The same code runs three times, against different data.
The credentials do not live in the code.
The database address, the API keys and the signing secrets are set in the hosting platform and read by the application at runtime. Each environment holds its own.
Nothing sensitive is committed. Anything that does get committed is in the history permanently. Rotating it is the only real fix.
One change, from a
laptop to live
What happens between the edit and the customer seeing it.
Four parts, one change, and nobody touched a server.
Both halves in one project, a database you never operate, and version control as the spine.
The stack is an opinion. Its value is that the opinion is already formed. Environments keep the real data away from the work in progress. The credentials stay out of the repository.