What backend is: server, API, database and everything in between

In the lesson on how a website works, the backend was the restaurant kitchen, and in the HTTP and JSON lesson we took requests and responses apart. Here we look at what happens inside the server between the two. MDN describes the job of server-side code as validating submitted data and requests, storing and retrieving data in a database, and sending the right data back to the client. In practice, a single request like book a haircut on Friday at 3 pm goes roughly this way:

Unlike browser code, server-side code has full access to the operating system and can be written in any language; MDN names this as the main difference between client-side and server-side programming. With that access comes responsibility. It is convenient to split it into five duties, using an online booking service for a salon as the example.

Authentication and authorization sound alike but are different steps. Authentication answers who is this, authorization answers what are they allowed to do. A user can be successfully authenticated and still have no right to cancel someone else's booking. Both get dedicated lessons in this direction.

Not everything has to happen while the user waits. Saving the booking does: without it you cannot say you are booked. Sending an SMS reminder, rebuilding a report or compressing an uploaded photo can happen a bit later. Such work goes into background jobs: the request handler puts a job on a queue and responds immediately, and a separate worker process takes jobs off the queue and runs them.

The Twelve-Factor App methodology describes these as process types: HTTP requests are handled by a web process and long-running background tasks by a worker process. The queue itself is another backing service on par with the database: a message broker such as RabbitMQ, a Redis store, or a jobs table in the same PostgreSQL. The choice depends on volume and reliability requirements; the background jobs lesson covers it in detail.

HTTP is stateless by default: every request is new to the server, which does not remember that the same browser signed in a second ago. To remember the user, the server issues a cookie with a session ID after sign-in, the browser attaches it to every following request, and the server uses the ID to look up the session data. This is how MDN describes the mechanism.

The key question is where session data, and everything else that must survive between requests, lives. It is tempting to keep it in a variable in process memory: that works on a laptop and breaks in production. The Twelve-Factor App requires application processes to be stateless and share-nothing, with anything that must persist stored in an external backing service. The reason is simple: a restart on deploy wipes process memory, and with several server instances the next request may land on a different one.

Users cannot see the backend, and developers see it only through logs. A log is a stream of events: request received, booking created, SMS service returned an error. The Twelve-Factor App advises the app not to manage log files but to write events to standard output (stdout), one per line; collecting, storing and searching them is the job of the environment: the hosting, the container platform, the log collection system.

• Log the method, path, status code, duration and request ID — that is how you find a problem
• Log errors with the stack trace on the server, and give the client a short message without internals
• Never log passwords, tokens, card numbers or full personal data
• Keep settings that differ between environments — database URL, service keys — in environment variables, not in code

The last point also comes from the Twelve-Factor App: config is separated from code, and the test is simple — the codebase could be made public at any moment without exposing a single credential. The same methodology calls the database, queue, mail service and cache backing services: the app reaches them by an address from config and does not care whether they are local or cloud-hosted. Swapping one database for another means changing a variable, not code.

Every responsibility in this lesson is the same in any stack; what changes is the language, the tooling and how much the framework does for you. MDN notes that the server side is almost never written without a framework: it takes care of routing, request parsing, sessions and database access. Frameworks range from batteries-included, like Django, to minimalist, like Express or Flask, where the missing pieces come from separate libraries.

For a learning project, pick the stack you already know. If you write frontend in JavaScript, start with Node.js: there is no need to learn a second language alongside server concepts. If you are learning Python, FastAPI gets you a working, documented API in a few dozen lines. If you are aiming at large companies and banking, look at Java and Spring Boot. In our experience, moving between stacks is easy once the backend duties themselves are clear: route, validation, logic, storage, permissions.

Put it all together on one service. A salon needs a website where a client chooses a service, a stylist and a time; the admin sees the schedule; the client gets a reminder the day before the visit. Before writing code, draw the backend on paper — you will see which parts are needed and where each piece of state lives.

From here the direction moves from tools to architecture. First Node.js: modules, npm and a first HTTP server without a framework. Then Express: a CRUD API with validation and a single error format. Parallel tracks cover Java with Spring Boot and Python with FastAPI or Django. After that come authentication, authorization, background jobs, backend testing and backend application layers. For storage you will need the Databases direction.