Backend development

What it is and why it exists

A backend is code that runs outside the user’s device and handles requests and state for an application. For an HTTP service, it receives a method, target URI, headers, and an optional body, then returns a status code, headers, and an optional body after applying its rules. It may run on one server, across several processes, or in a serverless runtime; “backend” names a responsibility, not a machine shape.

Clients shouldn’t own every business rule or receive direct database privileges. Pricing, resource authorization, and stock deductions need a controlled boundary that gives every client consistent results. The backend also connects short-lived network requests to longer-lived durable data.

To a client, the backend is first an API contract . The contract covers more than JSON fields: method semantics, paths, input limits, authentication, status codes, relevant response headers, and retry behavior all belong to it. Clients depend on these observable results, not on the framework or database behind them.

You meet a backend when a web form is submitted, a mobile app syncs data, a command-line tool checks status, or one service calls another. Every interaction crosses an unreliable network, so timeouts, broken connections, and duplicate requests are routine conditions rather than exotic edge cases.

What a backend actually owns

A small HTTP backend usually has these responsibilities:

1. Select an operation from the HTTP method and path, and reject combinations it hasn’t defined.
2. Parse and validate untrusted input before converting it into data the domain layer understands.
3. Authenticate the caller and authorize the specific resource and operation.
4. Preserve durable invariants across concurrent requests and process restarts.
5. Return stable responses and record enough context to diagnose failures.

Languages, frameworks, and databases are tools for those responsibilities. When you’re starting out, completing one testable request path in one language reveals the boundaries better than comparing several stacks at once. The examples here use Node 24’s built-in HTTP API and have no framework dependency.

How it works

An HTTP server parses bytes from a connection into a request object. The application selects a handler from the method and target, then uses middleware or explicit functions for cross-cutting work such as request identifiers, authentication, rate limiting, and logging. The handler validates input, invokes domain logic and storage, and finally encodes the result as an HTTP response.

The diagram shows a flow of responsibilities, not a required process layout. A small program can keep routing, application logic, and storage adapters in one codebase while maintaining clear inputs and outputs between them.

The life of one request

You can trace a request in this order:

1. The server reads the request line, headers, and body while applying size and time limits.
2. Request-scoped middleware establishes a request ID, logging context, and verified caller identity.
3. The router selects a handler by method and path, returning an explicit 404 or 405 when none matches.
4. The handler parses the transport format, validates fields, and calls a business operation that doesn’t depend on HTTP objects.
5. The storage layer starts a transaction when needed, checks durable constraints, and commits state changes.
6. Response mapping converts the result to a status, headers, and representation before request-scoped cleanup finishes.

Each request should have its own request context . A request ID, authenticated principal, and deadline belong to that request; they should not live in mutable module variables that another request can overwrite. Database connections may come from a shared pool, but the transaction and borrowed connection must be released when the request or business operation ends.

The contract comes before the handler

Write the observable contract before the route code. The table shows the minimum decisions for a create-task operation. Other choices can work, but their meaning cannot be left for each client to guess.

Transport validation proves only that the message has an acceptable shape. A string title doesn’t prove the caller may create a task in a project or that the project is still open. Authorization and domain invariants need separate checks, while durable uniqueness should also have a database constraint.

State and failure boundaries

Server memory is suitable for request-local values and rebuildable caches, not as the only record of business data. Worker processes have separate memory, a restart clears it, and two concurrent writers can observe different old values. Data that must survive a restart belongs in durable storage.

When the network disconnects, a client may not know whether the server committed an operation. This is an unknown outcome: no response does not prove that nothing happened. Safe retries rely on defined method semantics or, for non-idempotent creation, an idempotency protocol with atomic deduplication.

Error responses are part of the contract too. A production service shouldn’t send internal stacks or database messages to callers; it should return a stable machine-readable category, a suitable explanation, and a request ID. Problem Details is one standard error representation, but adopting it still requires you to define the service’s error types and fields.

Examples

The three examples add routing, input validation, and a real HTTP round trip in sequence. Each was run with local Node 24, and the shown output is the actual result.

Select an operation by method and path

The first example treats a request as ordinary data. The routing function handles only dispatch and response mapping, so you can test its outermost interface decisions before starting a network server.

GET /tasks and POST /tasks are different operations; matching only the path would conflate them. The creation branch uses 201 and Location to say a resource was created, while the unknown combination receives 404 instead of a fake success.

This function does not validate request.body or actually save a task. It matters that these missing boundaries stay visible: the next example adds validation, while persistence belongs to a real storage adapter rather than an array pretending to be one.

Turn untrusted input into a valid value

The validation function rejects non-object bodies, checks field types and limits, and returns a normalized value on success. It doesn’t depend on HTTP, so a unit test doesn’t need to listen on a port.

function validateTask(input) {
  if (input === null || typeof input !== "object" || Array.isArray(input)) {
    return { ok: false, errors: ["body must be an object"] };
  }

  const errors = [];
  if (typeof input.title !== "string" || input.title.trim() === "") {
    errors.push("title must be a non-empty string");
  } else if (input.title.length > 80) {
    errors.push("title must be at most 80 characters");
  }
  if (input.priority !== undefined && !["low", "normal", "high"].includes(input.priority)) {
    errors.push("priority is invalid");
  }

  return errors.length === 0
    ? { ok: true, value: { title: input.title.trim(), priority: input.priority ?? "normal" } }
    : { ok: false, errors };
}

const samples = [
  { title: "  Ship docs  ", priority: "high" },
  { title: "", priority: "urgent" },
  ["Ship docs"],
];

for (const sample of samples) {
  console.log(JSON.stringify(validateTask(sample)));
}

{"ok":true,"value":{"title":"Ship docs","priority":"high"}}
{"ok":false,"errors":["title must be a non-empty string","priority is invalid"]}
{"ok":false,"errors":["body must be an object"]}

The success result contains values downstream code can trust, while a failure can map to 400 Bad Request. Coercing with String(input.title) looks convenient but turns a missing value into the string "undefined"; strict checks preserve the real meaning of the error.

The length rule also needs a unit. JavaScript’s string.length counts UTF-16 code units, which are neither user-perceived characters nor UTF-8 bytes. The 80 here is an example contract; a real service must give its UI, API, and database the same tested rule.

Run a real HTTP round trip

The last example asks the operating system for a temporary port and sends requests with Node’s fetch(). sendJson() centralizes the media type and encoding, while the handler puts the same request ID on success and failure responses.

const { createServer } = require("node:http");

function sendJson(response, status, body) {
  response.writeHead(status, { "content-type": "application/json; charset=utf-8" });
  response.end(JSON.stringify(body));
}

const server = createServer((request, response) => {
  const requestId = "req-7";
  if (request.method === "GET" && request.url === "/health") {
    sendJson(response, 200, { status: "ok", requestId });
    return;
  }
  sendJson(response, 404, { error: "not_found", requestId });
});

server.listen(0, "127.0.0.1", async () => {
  const address = server.address();
  const baseUrl = `http://127.0.0.1:${address.port}`;

  for (const path of ["/health", "/missing"]) {
    const response = await fetch(`${baseUrl}${path}`);
    console.log(response.status, await response.text());
  }

  server.close();
});

200 {"status":"ok","requestId":"req-7"}
404 {"error":"not_found","requestId":"req-7"}

Listening on port 0 avoids hard-coding a test port that might already be occupied. The application reads the assigned address from server.address() and closes the server afterward; a production process must also stop accepting requests, drain in-flight work, and set a forced-exit deadline.

The health endpoint says only that this process can handle that request. It doesn’t prove the database is writable, the queue works, or a particular business capability is ready. Separate liveness from readiness and point the load balancer at the endpoint whose semantics match the deployment.

Pitfalls

Treating a request body as domain data

Fix: allowlist fields for the operation, parse types and limits strictly, then supply protected fields from authenticated identity and server state. Database constraints enforce final durable invariants, while application validation returns useful errors early.

Treating an in-process array as a database

Fix: state which data may be lost and which must persist. Put uniqueness, foreign keys, and atomic updates in storage that can provide those guarantees, then catch and map constraint conflicts in the application.

Returning success before commit

Fix: define the commit point and the retry protocol for unknown outcomes. When a record and event must move together, write the business record and an outbox entry in one transaction, then publish through a separate worker.

Hiding every result behind one status

Fix: define a small stable set of status codes and error types for observable outcomes. Reserve 500 for unexpected server failures, record the internal cause, and keep stacks, SQL, and secrets out of the external response.

Stacking middleware without checking order

Fix: draw the inbound and outbound order and record which context fields each middleware reads and produces. Send unauthenticated, unauthorized, and valid requests to every protected route instead of trusting a global configuration that looks right.

Giving a health check side effects

Fix: keep liveness checks cheap and free of business side effects. Readiness should check only dependencies required to accept traffic, with short deadlines for each probe; put detailed diagnostics behind a protected operations interface.

Further reading

• RFC 9110: HTTP Semantics
• Node.js v24 documentation: HTTP
• MDN: Overview of HTTP
• OWASP REST Security Cheat Sheet