Full stack developer

The stack, tool by tool.

What sits in each layer, what each piece is for and why it is there rather than another. With a link to the official documentation for every one.

Backend NodeJS, TypeScript, Python, PHP, C#
Frontend React
Systems Linux, Apache, MySQL, PostgreSQL, MongoDB

How each piece gets chosen

The tool is chosen after the problem, never before. And nearly always the most boring of the ones that work wins.

A stack is not a list of fashions: it is a set of decisions somebody will have to maintain for years, sometimes without me. That is why it weighs so much what the team that stays already knows how to do, and what has public documentation, supported versions and a community to ask.

The process decides, not the language First what has to happen and what data has to be stored. The language is the last decision, and sometimes the answer is “whatever you already use”.
Boring wins Technology with years behind it, maintained versions and answers on the internet. The new thing has to justify why it is worth the risk.
Data outlives code The application gets rewritten; the data does not. The relational model is designed to last and the migrations are kept as part of the project.
One way to do each thing Two ways to read a configuration or three to run a query is debt dressed up as freedom.
Every dependency has a price Every library has to be updated, audited and understood the day it fails. If its job is forty lines, you write them.
The machine is part of the product System, web server, certificates and backups are part of the delivery: an application that cannot be deployed twice the same way is not finished.

Piece by piece.

What each tool is, what I use it for and where its official documentation lives.

NodeJS A runtime for JavaScript on the server, with a non-blocking input and output model. It suits work that mostly consists of waiting: many simultaneous requests talking to databases and third-party APIs. Example: The backend of an application that queries external services while serving several users at once, without opening a process for each one. Source: NodeJS documentation
TypeScript JavaScript with types checked before running. It does not change what the program does: it changes when you find out it is wrong, which becomes while writing it instead of in production. Example: When a model field goes from required to optional, the compiler lists the thirty places to review. Without types, that list is written by the user who hits the bug. Source: TypeScript documentation
Python A general-purpose language, among the most readable there is, with a broad standard library and a strong ecosystem in data handling and automation. Example: The processes with no screen: reading a file a supplier sends, reconciling it with what is in the database and reporting the differences. Source: Python 3 documentation
PHP A language built for the web, with a simple request model —each visit starts and ends— and available on any hosting. Since version 8 it has types, enums and a just-in-time compiler. Example: This site, with no dependencies and no build. Also the projects that have to live on shared hosting and survive with nobody administering a server. Source: PHP manual
C# and .NET Microsoft’s typed language and platform, with very solid tooling and a strong presence in business management software. It is the natural ground when you have to integrate with the Windows world. Example: Integrations with ERP and management software installed on the client’s premises, where the other end is already written in that world. Source: C# documentation
APIs · HTTP and REST How two programs talk to each other: addresses with meaning, methods with semantics and status codes that actually mean something. It is specified in the HTTP RFCs; it is not a matter of taste. Example: Getting the shop, the accounting and the warehouse to share the same customer and the same stock without anyone copying data by hand between programs. Source: RFC 9110, HTTP Semantics (IETF)
React A library for building interfaces out of components, where the screen is the result of a state. It fits when there is a lot of interaction and the same data appears in several places at once. Example: A panel where you filter, sort and edit without reloading, and where the counter at the top always has to agree with the table below. Source: React documentation
Linux The system nearly everything ends up running on. Knowing how to administer it is part of the craft: users and permissions, services, certificates, firewall, backups and logs. Example: Leaving an application served over HTTPS, with automatic certificate renewal, a verified daily backup and somewhere to look when something fails at three in the morning. Source: The Twelve-Factor App
Apache HTTP Server A veteran, heavily documented web server with fine control over rewrites, headers and encryption. It is what answers the request before it reaches the application. Example: The permanent redirects for a site’s old addresses, so a link published ten years ago still lands where it should. Source: Apache 2.4 documentation
MySQL A very widespread relational database, present on any hosting. It is more than enough when the model is clear and the load is that of a normal business application. Example: The base of a management application that lives on shared hosting and has to be able to move provider without drama. Source: MySQL reference manual
PostgreSQL A relational database with strict rules, serious transactions and a lot of power in queries, JSON and types. It is what I choose when the data model is the heart of the problem. Example: A process with states, dates and permissions where a badly written query must not return another client’s data: better that the database prevents it, not only the code. Source: PostgreSQL documentation
MongoDB A document database with no fixed schema. It fits when what you store are whole documents of variable shape; it goes badly when there were relations after all and you find out late. Example: Storing responses from an external service exactly as they arrive, with their shifting fields, without redoing the schema every time the provider adds one. Source: MongoDB manual
Git Version control: the history of why the code is the way it is. Used well, the history answers questions no comment can answer. Example: Every change with its reason written down and its prefix, so release notes come out of the history rather than out of somebody’s memory. Source: Git documentation

Questions.

Why so many languages instead of one?

Because the work is not always the same and because many jobs consist of integrating with something that already exists. If the client’s ERP lives in the Microsoft world, that is where the integration gets written; if the process is file handling, Python solves it in twenty lines. Choosing the language out of personal taste is paid for later by whoever maintains it.

MySQL or PostgreSQL?

If the data model is the heart of the problem —states, permissions, calculations, reports—, PostgreSQL. If the application has to live on any hosting and the model is simple, MySQL does the job without argument. What I do not do is choose a database before the model is drawn.

What about mobile?

When fieldwork has to carry something around, it becomes a mobile application connected to the same system, not a separate screen with its own data. Kokai, for instance, is published on the App Store.

Where is all this hosted?

Wherever the project calls for, with one rule: if there is personal data involved, the hosting is chosen knowing what the General Data Protection Regulation requires, and that is decided before deploying, not after.

Official documentation and standards.

Every tool links to its official documentation, and whatever is a standard, to the standard.

Where to go next.

Shall we talk?

Not sure what fits your case?

Tell me the process and I will tell you what I would build it with, and why.

Write to me