Skip to content
academia.sh
tr
Log in

Course Beginner

Server-Side Fundamentals

By the end of this course

Start course

01

The Backend's Role

The responsibilities the server side takes on: the responsibility boundary with the client, the roles of the web server and the runtime, a request's lifecycle from accept to response, and the middleware chain that orders cross-cutting concerns.

  1. 01 What the Backend Does The three responsibilities the server side takes on: keeping state in a single place, the point where business rules are enforced, and integration with systems the client cannot reach.
  2. 02 The Client and Server Responsibility Boundary The criteria that decide the choice when the same computation can be done on either side; bytes transferred, number of network round trips, and how binding the decision is are measured and compared.
  3. 03 The Web Server Concept The server side's three distinct roles: serving files with the correct headers, splitting requests by path, and handing a request off to a backend server, each set up and measured as a separate process.
  4. 04 The Application Runtime The process model beneath the application: how long work that blocks the event loop makes other requests wait is measured, the limit of the thread pool is shown, and why the unit of scaling is the process is counted with workers that share the same port.
  5. 05 The Request Lifecycle The path a request takes from connection accept to the last byte written is split into seven stages; timestamping each stage measures the order and durations, and shows that a connection and a request are separate things, and when the status line becomes irreversible.
  6. 06 The Middleware Chain An onion-model chain that gathers the work repeated on every request into one place is built; the same links are run in four separate orders, and the placement of identity checking relative to logging, the scope of the error catcher, and the correctness of the log lines are measured and compared.

02

Application Scaffolding

The server application's carrying structure — layer and module layout, configuration read from the environment and validated at startup, secrets kept separate, structured logging, a shared error response, and portability principles.

  1. 01 Project Structure Two layouts for files, layer-oriented and feature-oriented, are compared by measurement; domain, data, transport, and composition responsibilities are separated, and the dependency direction rule is wired to an audit program that reports a violation through its exit code.
  2. 02 Configuration Management Configuration read from environment variables is defined by a schema; type, range, and option validation happens at startup, every problem is reported at once, and the application's crash with a sysexits exit code on an invalid environment is measured.
  3. 03 Separating Secrets The boundary between configuration and a secret is drawn by exit paths; two-layer redaction based on the key name and on the value itself is applied, internal detail is kept out of the client while staying in the log, and a leak audit catches an unredacted field through its exit code.
  4. 04 Logging Setup Log lines are produced as JSON objects; the request context is carried through asynchronous local storage, deep layers record the request id without taking it as a parameter, the level threshold determines the line count, and every line belonging to a single request is gathered with a query.
  5. 05 Error Handling Layer Client error is separated from programmer error, and a single layer translates both into the same response shape; the text sent to the client comes from a fixed table, internal detail stays only in the log, and the response bodies are tested for leaks across seven scenarios.
  6. 06 Twelve-Factor App Principles The decisions made in this section are mapped to twelve principles named as a portability contract; a single build running unchanged across two environments is measured with a file hash, and fast startup and graceful shutdown are measured through the completion of an in-flight request.

03

Static and Dynamic Serving

What the running application skeleton gives back to the outside; serving the file on disk with a validator and cache directive, rendering the view from a template on the server, accepting an incoming file within limits, and bringing dependent services up locally.

  1. 01 Static File Serving How a file on disk turns into an HTTP response: the document root and path resolution, content type and length, the conditional request enabled by an entity tag, the two classes of cache directive, and the decision to hand the load off to a content delivery network.
  2. 02 Server-Side Templating Building the view from data on the server: the template engine's parse and render steps, escaping as the default, raw output requested by an explicit marker, the difference the attribute context makes, and separating the layout template from the page template.
  3. 03 File Upload and Storage Accepting a file coming from outside within limits: the two-layer size limit formed by the declared length and the stream counter, getting the rejection to the other side, determining the type from content instead of the extension, separating the store directory from the served directory, and generating the file name on the server.
  4. 04 Local Development Environment Bringing dependent services up on the developer's machine: how startup order forms a chain, how a readiness check is built from a connection attempt and backoff, why a fixed wait is a guess, and how the same environment is reproduced on two machines through version pinning and the seed data rule.

Start typing to search.

↑↓ ↵ Esc navigate · open · close