Back-End Development

Back-end development is the craft of writing the application code that runs on a server: accepting requests, enforcing business rules, coordinating with data stores, and returning responses. It is the layer between what the user sees and the infrastructure that keeps things running.

This section covers topics specific to writing server-side application code. Adjacent concerns live in their own sections — the table below is the map.

Scope

What belongs here:

• API design — REST conventions, GraphQL schema design, gRPC service definitions
• Authentication & authorization — OAuth flows, JWT handling, RBAC, session management
• Server frameworks — choosing and using Express, Fastify, Gin, FastAPI, Spring Boot, and friends
• Concurrency — event loops, goroutines, thread pools, async/await, and the bugs they produce
• Real-time communication — WebSocket, SSE, long polling, scaling persistent connections
• Resilience — circuit breakers, retries, rate limiting, graceful degradation

What does not belong here (and where to find it):

How the Pieces Fit

A typical request touches all of these layers:

Client
  → API layer (api-design)
    → Auth middleware (authentication)
    → Framework router/handler (server-frameworks)
      → Business logic (concurrency if parallel work needed)
        → Data store / external service
      ← Response (resilience patterns if downstream fails)
  ← Client

Real-time features (WebSocket, SSE) break out of the request-response cycle but still depend on authentication, framework support, and resilience under load.

Reading Order

If you are new to back-end development, a reasonable path:

1. Server Frameworks — pick a framework, get a "hello world" running
2. API Design — learn the conventions your endpoints should follow
3. Authentication — secure those endpoints
4. Concurrency — understand how your runtime handles parallel work
5. Resilience — handle the failures that production will throw at you
6. Real-Time — add persistent connections when request-response isn't enough

If you are experienced, each article is self-contained — jump to whatever is relevant.

Principles That Cut Across Every Page

A few convictions that show up repeatedly in this section:

• The framework is not the application. Business logic should be testable without booting the HTTP server. If swapping Express for Fastify would require rewriting your domain layer, the coupling is too tight.
• Fail loudly, recover gracefully. Log the error, return a useful status code, and keep the server alive. Silent swallowing of exceptions is the number-one source of "it works on my machine" production bugs.
• Latency budgets are real. Every middleware, every database call, every serialization step consumes part of a finite budget. Know where the time goes before you optimize.
• Security is not a feature — it's a constraint. Authentication, authorization, input validation, and rate limiting are not nice-to-haves. They ship with the first endpoint or they never ship at all.