Backend and Web Development Foundations

Introduction

Modern digital platforms depend on software that receives requests, processes information, applies business rules, stores and retrieves data, and returns useful results. The visible interface may be a web page or mobile application, but much of the platform’s intelligence operates behind that interface. This hidden or partially hidden layer is the backend.

Backend development with Node.js and Express begins with a clear understanding of how the web works. Before building routes, controllers, authentication systems, or databases, developers must understand the communication model that connects clients and servers. This includes client-server architecture, domain-name resolution, TCP/IP networking, HTTP and HTTPS, web servers, APIs, statelessness, and data serialization.

These concepts are not merely theoretical. They help developers diagnose failed requests, design reliable APIs, select appropriate security controls, understand performance constraints, and communicate effectively with infrastructure and operations teams.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the roles of clients, servers, networks, and backend systems;
• describe how DNS translates domain names into network addresses;
• distinguish the main responsibilities of TCP/IP, HTTP, and HTTPS;
• explain how a web request is processed from entry to response;
• compare web servers, application servers, and databases;
• define APIs and identify common API design principles;
• explain statelessness and its implications for authentication and scalability;
• describe serialization and deserialization in web applications;
• identify major backend concerns, including reliability, security, observability, and ethics.

1. The Role of the Backend

A digital platform usually contains at least three conceptual layers:

1. Presentation layer: the interface through which users interact with the system.
2. Application layer: the business logic that interprets requests and makes decisions.
3. Data layer: systems that store, retrieve, and manage persistent information.

The backend commonly includes the application layer and the services supporting it. It may also include databases, caches, message queues, file storage, authentication services, payment integrations, and monitoring systems.

Consider an online learning platform. A student’s browser displays a course page, but the backend may perform the following actions:

• identify the student from an authentication credential;
• retrieve the appropriate course record;
• determine whether the student is enrolled;
• calculate course progress;
• obtain comments or assessment results;
• return the information in a format the browser can display.

The backend therefore acts as a controlled intermediary between users, data, and external services. It should not be understood simply as “the database.” A database stores and manages data, while backend application code determines how that data is used and exposed.

2. Client–Server Architecture

The client–server model divides responsibilities between a client, which initiates communication, and a server, which provides a service. A client may be a browser, mobile application, command-line tool, or another server. A server is a program or system that listens for requests and responds according to a defined protocol.

A typical interaction is:

1. The client constructs a request.
2. The request travels through one or more networks.
3. The server receives and interprets it.
4. Application logic validates the request and performs work.
5. The server sends a response.
6. The client interprets and presents the response.

Figure: A simplified client–backend–data-services interaction.

The model is logical rather than strictly physical. A single server may perform several roles, and a large platform may distribute one role across many machines or cloud services. The important principle is separation of responsibilities and communication through defined interfaces.

Advantages and limitations

Client–server architecture centralizes important rules and data, supports multiple client types, and makes maintenance easier because a business rule can be changed on the server rather than duplicated in every client. It also supports access control and auditing in a central location.

However, clients depend on network availability and server responsiveness. A poorly designed backend can become a bottleneck or single point of failure. Centralization also means that server outages, security breaches, or incorrect business logic can affect many users simultaneously.

3. From Domain Name to Server: DNS

People use names such as example.com, while networks ultimately communicate using IP addresses. The Domain Name System (DNS) is a distributed naming system that maps domain names to records, commonly including IPv4 addresses in A records and IPv6 addresses in AAAA records.

When a user enters a web address, a simplified resolution process is as follows:

1. The operating system or browser checks its local cache.
2. If no valid result exists, the device asks a recursive DNS resolver, often operated by an internet service provider or organization.
3. The resolver may consult authoritative DNS servers through the DNS hierarchy.
4. The resolver returns an address and stores it temporarily according to the record’s time to live (TTL).
5. The client uses the address to establish a network connection.

DNS is hierarchical. Root servers direct queries to top-level-domain servers, such as those responsible for .com, and authoritative name servers provide records for a specific domain. Caching improves speed and reduces traffic, but it also means that changes may not appear everywhere immediately.

DNS does not normally deliver the web page itself. It helps the client locate a service. A domain may resolve to a load balancer, content delivery network, reverse proxy, or web server rather than directly to an application process.

4. TCP/IP and the Journey of a Request

The TCP/IP protocol suite provides the fundamental communication mechanisms used by the internet. It is commonly explained through layers, although practical implementations may group them differently.

Internet Protocol (IP)

IP provides addressing and routing. An IP packet contains source and destination addresses, allowing routers to forward it across interconnected networks. IP itself does not guarantee delivery, preserve order, or prevent duplication.

Transmission Control Protocol (TCP)

TCP provides a reliable, ordered byte stream between endpoints. It uses connection establishment, acknowledgements, retransmission, flow control, and congestion control. Reliability does not mean that communication is always fast: lost packets, congestion, or distant endpoints can increase latency.

HTTP traditionally uses TCP, commonly through port 80 for HTTP and port 443 for HTTPS. Modern HTTP/3 uses QUIC, which operates over UDP while implementing transport features suitable for HTTP. The conceptual separation remains useful: application protocols rely on transport and network mechanisms to deliver data.

A useful performance concept is round-trip time (RTT), the time required for a signal to travel to a destination and for a response to return. A request that requires several sequential network exchanges can feel slow even when each individual operation is small. Backend developers therefore reduce unnecessary round trips, use connection reuse, and design efficient data access.

5. HTTP: The Web’s Application Protocol

Hypertext Transfer Protocol (HTTP) defines how clients and servers communicate web resources and application data. HTTP is a request–response protocol. A request generally contains a method, target resource, headers, and optionally a body. A response contains a status code, headers, and optionally a body.

A simplified request might be:

GET /courses/42 HTTP/1.1
Host: learning.example
Accept: application/json
Authorization: Bearer <credential>

A corresponding response might be:

HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"title":"Backend Foundations"}

HTTP methods

A method’s semantics matter. A GET request should not be used to perform a destructive operation, because browsers, crawlers, caches, or prefetching mechanisms may issue GET requests automatically.

Safe means that the client does not request a state-changing operation. Idempotent means that making the same request multiple times has the same intended effect as making it once, although responses, logs, timestamps, or other side effects may differ. A PUT operation that sets a user’s display name to “Mina” is designed to be idempotent; a POST operation that creates a new order generally is not unless the application adds an idempotency mechanism.

Status codes

HTTP status codes communicate the broad result of a request.

• 2xx success: the request was successfully processed, such as 200 OK, 201 Created, or 204 No Content.
• 3xx redirection: further action or another location is involved.
• 4xx client error: the request is invalid, unauthorised, forbidden, or refers to a missing resource.
• 5xx server error: the server failed to complete an otherwise valid request or acted as a gateway to a failed service.

Status codes are not a substitute for a useful response body or logging, but they provide standardized signals to clients, caches, monitoring tools, and developers.

Headers, body, and content negotiation

Headers carry metadata. Examples include Content-Type, Accept, Cache-Control, Authorization, Cookie, and User-Agent. The body carries content such as HTML, JSON, an image, or an uploaded file. Content-Type describes the format of the body being sent, while Accept indicates formats the client can receive.

HTTP is extensible. Applications can define custom headers, but standard headers and established conventions should be preferred where applicable.

6. HTTPS and Web Security

HTTPS is HTTP carried through a secure TLS connection. TLS provides encryption in transit, integrity protection, and server authentication through digital certificates. Encryption prevents intermediaries from easily reading the content; integrity protection helps detect alteration; certificate validation helps the client verify that it is communicating with the intended domain.

HTTPS does not automatically make an application secure. It does not prevent a server from storing passwords incorrectly, accepting malicious input, exposing excessive data, or authorizing the wrong user. It protects the communication channel, not every layer of the system.

Backend best practices include:

• use HTTPS for all production traffic;
• protect credentials and secret keys outside source code;
• validate and authorize every sensitive operation on the server;
• use secure cookie attributes such as Secure, HttpOnly, and an appropriate SameSite policy;
• avoid returning passwords, tokens, or unnecessary personal data;
• keep dependencies and TLS configurations maintained;
• log security events without exposing confidential values.

Authentication answers “Who is the user?” Authorization answers “What may this user do?” Confusing these concepts is a common source of security defects.

7. Web Servers, Application Servers, and Reverse Proxies

A web server accepts network connections and serves static content or forwards dynamic requests. Examples include Nginx, Apache HTTP Server, and Node.js HTTP servers. A Node.js application can itself listen for HTTP requests, but production architectures often place a reverse proxy or load balancer in front of it.

An application server runs application logic. In a Node.js/Express system, the application server may perform routing, validation, authentication, data access, and response construction.

A reverse proxy receives requests on behalf of backend servers. It may terminate TLS, serve static files, compress responses, enforce connection policies, route traffic, and distribute requests among several application instances.

A load balancer distributes traffic across healthy servers. This improves capacity and availability, but it introduces requirements such as health checks, consistent configuration, and appropriate session design.

These roles may be separate or combined. The architectural distinction helps developers understand where a failure occurs. For example, a 502 response may indicate a gateway’s inability to obtain a valid response from an upstream application, while a 500 response generally indicates an application-side failure after the request reached that application.

8. APIs and Service Interfaces

An Application Programming Interface (API) is a defined way for software components to communicate. A web API commonly exposes resources or operations through HTTP endpoints.

For example:

GET    /api/products
GET    /api/products/18
POST   /api/products
PATCH  /api/products/18
DELETE /api/products/18

A well-designed API documents:

• available endpoints and methods;
• required parameters and request bodies;
• authentication requirements;
• response formats and status codes;
• validation and error behavior;
• pagination, filtering, and sorting rules;
• versioning and compatibility expectations.

REST is a style of designing networked systems around resources, representations, uniform interfaces, and stateless interactions. Not every HTTP API is fully RESTful, and REST is not the only API approach. GraphQL allows clients to request selected fields through a query language, while gRPC commonly uses strongly typed service definitions and efficient binary serialization. The appropriate choice depends on client needs, organizational constraints, performance requirements, and interoperability.

Good APIs use consistent naming, meaningful status codes, predictable error structures, and least-privilege access. They should not expose internal database structure unnecessarily. An API is a public or organizational contract, so changes require compatibility planning.

9. Statelessness, State, and Scalability

In a stateless interaction, each request contains the information necessary for the server to process it. The server does not depend on unrecorded conversational memory from a particular previous request.

Statelessness does not mean that the system has no state. User accounts, shopping carts, and orders are stateful business concepts and may be stored in databases. It means that request processing does not require a particular application instance to retain temporary session memory.

Stateless design makes horizontal scaling easier. If several application instances exist, a load balancer can send successive requests to different instances, provided shared state is stored in an accessible system such as a database or cache. Alternatives include server-side sessions with a shared session store or client-held signed tokens. Each approach has security, revocation, size, and operational trade-offs.

A signed token is not necessarily encrypted. Signing helps detect modification; encryption is required when the contents must remain confidential. Tokens should have suitable expiration, audience, issuer, and scope controls, and sensitive systems need a strategy for revocation or credential rotation.

10. Serialization and Data Exchange

Serialization converts an in-memory data structure into a format suitable for storage or transmission. Deserialization reconstructs a usable data structure from that format.

JSON is widely used because it is readable and supported across languages:

{
  "id": 18,
  "name": "Keyboard",
  "available": true,
  "tags": ["hardware", "office"]
}

Serialization requires clear decisions about field names, optional values, dates, numbers, character encoding, and nested structures. JSON does not have a native date type; applications commonly use a documented string representation such as an ISO 8601 timestamp. Large integers can create precision problems in some environments, so their representation must be agreed upon.

Binary formats such as Protocol Buffers may provide compact messages and strong schemas. XML remains important in some enterprise and government systems. The format should be selected according to interoperability, readability, size, tooling, validation, and long-term compatibility.

Never trust deserialized input merely because it is syntactically valid. The backend must validate type, length, range, allowed values, and business rules. Serialization and validation are separate concerns: parsing determines whether data has a recognizable format, while validation determines whether it is acceptable.

11. Processing a Request in Node.js and Express

A request entering an Express application typically passes through a pipeline:

1. The operating system and Node.js accept the connection.
2. Express middleware processes general concerns such as logging, parsing, or CORS policy.
3. The router matches the HTTP method and path.
4. Authentication identifies the caller when required.
5. Authorization checks permissions.
6. Validation checks parameters and body data.
7. Controller or service logic performs the use case.
8. Data-access code communicates with a database or external service.
9. The application serializes a response.
10. Error-handling middleware deals with failures consistently.

Middleware should have a clear responsibility and ordering. For example, a route cannot use parsed JSON data until the relevant body-parsing middleware has run. Error responses should avoid leaking stack traces or internal implementation details in production.

A maintainable application separates transport concerns from business rules. A controller can translate an HTTP request into an application operation, while a service layer can implement rules that may also be used by background jobs or other interfaces.

12. Worked Request Example

Suppose a client sends:

POST /api/orders HTTP/1.1
Content-Type: application/json
Authorization: Bearer credential

{"productId":18,"quantity":2}

A professionally designed backend might process it as follows:

• The server verifies the TLS connection and parses the request.
• Authentication middleware validates the credential.
• Validation checks that productId is an integer and quantity is positive and within an allowed limit.
• Authorization confirms that the authenticated user may place an order.
• The service checks product availability and current price in a transactionally appropriate manner.
• The order is created and assigned an identifier.
• The response is serialized as JSON with status 201 Created.

If the product does not exist, the system may return 404. If the input is malformed, it may return 400 or 422 according to the API contract. If the user is authenticated but lacks permission, 403 is appropriate. If an unexpected database failure occurs, the server should return a suitable 5xx response, log diagnostic information securely, and avoid exposing database details.

13. Illustrative Case: An Online Appointment Platform

Background

A small health-services organization launches an online appointment platform. Patients use a browser or mobile application to find providers, view availability, and book appointments. Staff use a separate dashboard.

Problem

The first version stores appointments in application memory. It works during testing with one server, but appointments disappear when the process restarts. When a second server is added, users see inconsistent availability because each server has different memory. The system also returns overly detailed error messages.

Analysis

The design confuses temporary process memory with durable business state. It is not horizontally scalable and creates a risk of double booking. The client also receives internal database information, creating a security and maintenance problem.

Approach and solution

The team moves appointments and provider schedules to a shared database. The booking operation is designed around a transaction or equivalent concurrency-control mechanism so that two requests cannot successfully reserve the same time slot. The API uses HTTPS, authenticated access, server-side authorization, validated request bodies, and consistent error responses.

The application is placed behind a reverse proxy and two Node.js instances. Since requests may reach either instance, session information is stored in a shared session store or represented through carefully managed credentials. Logs include request identifiers, status codes, and timing information but exclude medical details and authentication secrets.

Outcome

Restarting an application instance no longer deletes appointments. Both instances use the same source of truth, and booking conflicts are handled by the data layer rather than by unreliable local memory. Clients receive stable API responses, while detailed diagnostics remain available to authorized operators.

Learning points

• Durable business state belongs in an appropriate persistent system.
• Stateless request processing supports horizontal scaling.
• Concurrency must be considered in operations such as booking.
• Security includes authorization, data minimization, and safe error handling.
• Observability is necessary for operating a distributed service.

14. Reliability, Performance, and Observability

Backend quality includes more than functional correctness. Important operational properties include:

• Availability: whether the service is usable when needed.
• Reliability: whether it performs correctly over time.
• Latency: how long an operation takes.
• Throughput: how much work can be completed in a period.
• Scalability: how effectively capacity increases as demand grows.
• Resilience: how well the system handles component failure.

Developers should measure rather than guess. Logs record events, metrics summarize behavior, and traces follow a request across services. Useful measurements include response latency, error rate, request volume, database wait time, and resource utilization. A request identifier helps connect events across components.

Caching can reduce repeated work, but stale data and invalidation must be managed. Retries can help with transient failures, but careless retries can multiply load or duplicate non-idempotent operations. Timeouts, bounded retries, circuit breakers, and graceful degradation are common resilience techniques.

15. Ethical, Legal, and Governance Considerations

Backend systems often process personal, financial, educational, or health-related information. Professional developers should apply data minimization, purpose limitation, access control, retention policies, and secure deletion where required by law or organizational policy.

Important questions include:

• What data is collected, and is it necessary?
• Who may access it, and how is access audited?
• How long is it retained?
• Can users correct or delete information where applicable?
• Is automated decision-making explainable and tested for unfair outcomes?
• Are third-party services transferring data across jurisdictions?

Accessibility and inclusion also belong in backend design. An API should communicate clearly, support appropriate error handling, and avoid assumptions that exclude users or client technologies. AI-enabled services require additional care concerning training data, privacy, hallucinated output, bias, human oversight, and accountability. An AI component does not remove the backend’s responsibility to validate, authorize, monitor, and govern its behavior.

16. Best Practices for Beginning Node.js/Express Developers

1. Learn HTTP semantics before designing routes.
2. Validate all input at the server boundary.
3. Separate authentication from authorization.
4. Use environment-based configuration and protect secrets.
5. Return consistent status codes and error structures.
6. Keep controllers thin and business logic testable.
7. Use timeouts for external calls and handle failures explicitly.
8. Log useful operational information without logging secrets or unnecessary personal data.
9. Document API contracts and version breaking changes.
10. Test success, validation failure, authorization failure, dependency failure, and concurrency cases.
11. Use HTTPS and maintain dependencies.
12. Design for deployment reality: restarts, multiple instances, partial failures, and observability.

Chapter Summary

The backend is the part of a digital platform that processes requests, applies business rules, accesses data, integrates services, and returns responses. Client–server architecture separates request initiators from service providers, while DNS maps human-readable domain names to network destinations. TCP/IP supplies addressing and transport mechanisms; HTTP defines web request–response semantics; HTTPS adds TLS-based confidentiality, integrity, and server authentication.

Web servers, reverse proxies, application servers, databases, and APIs have related but distinct responsibilities. APIs are contracts between software components and should use consistent methods, representations, status codes, validation, and security controls. Statelessness concerns how requests are processed, not whether business data exists, and it supports horizontal scaling when shared state is stored appropriately. Serialization converts data for communication, but deserialization must always be followed by validation.

A Node.js/Express request commonly passes through middleware, routing, authentication, authorization, validation, business logic, data access, serialization, and error handling. Professional backend development also requires attention to performance, reliability, observability, privacy, ethics, and governance.

Key Terms

Client: A program or device that initiates a request for a service.

Server: A program or system that receives requests and provides a service.

Backend: Application and supporting systems that process requests, enforce rules, and manage data.

DNS: The distributed system that maps domain names to network records.

IP: The protocol that provides addressing and routing between networks.

TCP: A transport protocol providing an ordered and reliable byte stream.

HTTP: The application protocol used for web communication.

HTTPS: HTTP protected by Transport Layer Security.

TLS: A security protocol providing encryption, integrity, and authenticated communication.

API: A defined interface through which software components communicate.

Endpoint: A specific API location and operation available to a client.

Statelessness: A design condition in which each request contains the information needed for processing.

Serialization: Conversion of data into a transmissible or storable representation.

Deserialization: Reconstruction of usable data from a serialized representation.

Middleware: Software that processes requests or responses within an application pipeline.

Authentication: Verification of a user or system identity.

Authorization: Determination of what an authenticated identity may do.

Reverse proxy: A server that receives requests and forwards them to backend services.

Load balancer: A component that distributes requests among service instances.

Observability: The ability to understand system behavior through logs, metrics, and traces.

Review Questions

Short Answer Questions

1. What are the main responsibilities of a backend system?
2. What problem does DNS solve?
3. How does HTTPS differ from HTTP?
4. Define serialization and deserialization.
5. What is the difference between authentication and authorization?

Long Answer Questions

1. Explain the complete journey of a browser request from domain-name entry to server response.
2. Compare the responsibilities of a web server, reverse proxy, application server, and database.
3. Explain HTTP methods, status-code classes, headers, and message bodies.
4. Discuss statelessness and explain why it can support horizontal scaling.
5. Describe a secure and maintainable request-processing pipeline in Node.js and Express.

Analytical / Application Questions

1. An API works correctly with one application instance but produces inconsistent shopping carts after deployment to three instances. Analyze the likely architectural cause and propose a solution.
2. Design the endpoint behavior for creating an appointment, including method, status codes, validation, authentication, authorization, and concurrency concerns.
3. A team proposes sending database error messages directly to clients to simplify debugging. Evaluate this proposal and recommend a safer operational approach.

Multiple Choice Questions with Answers

Question 1

Which component primarily maps a domain name such as example.com to an IP address?

A. DNS

B. TCP

C. HTML

D. A database transaction

Correct Answer: A. DNS

Question 2

Which HTTP method is conventionally used to retrieve a representation without requesting a state-changing operation?

A. POST

B. GET

C. PATCH

D. DELETE

Correct Answer: B. GET

Question 3

What additional protection does HTTPS provide compared with ordinary HTTP?

A. Automatic authorization of every user

B. Guaranteed application correctness

C. TLS-based confidentiality and integrity in transit

D. Permanent storage of all requests

Correct Answer: C. TLS-based confidentiality and integrity in transit

Question 4

Which statement best describes stateless request processing?

A. The system cannot store any business data

B. Each request contains the information needed for processing

C. Only one client may connect to the server

D. The server must restart after every request

Correct Answer: B. Each request contains the information needed for processing

Question 5

What is the main purpose of serialization in a web application?

A. To convert data into a format suitable for transmission or storage

B. To encrypt every password automatically

C. To assign IP addresses to clients

D. To replace authorization checks

Correct Answer: A. To convert data into a format suitable for transmission or storage

Question 6

A client sends valid JSON but omits a required product identifier. Which backend concern should detect this first?

A. Input validation

B. DNS resolution

C. TLS certificate issuance

D. Load balancing

Correct Answer: A. Input validation

Question 7

Which status-code class generally indicates that the server failed while processing an otherwise usable request?

A. 1xx

B. 2xx

C. 4xx

D. 5xx

Correct Answer: D. 5xx

Question 8

What is the primary role of a reverse proxy?

A. To replace all application business rules

B. To receive requests and forward them to backend services

C. To serialize only database indexes

D. To act as a web browser for the user

Correct Answer: B. To receive requests and forward them to backend services

Question 9

Which statement correctly distinguishes authentication from authorization?

A. Authentication determines permissions; authorization identifies a user

B. Authentication identifies a user; authorization determines permitted actions

C. They are identical terms with no practical distinction

D. Authorization occurs only during DNS resolution

Correct Answer: B. Authentication identifies a user; authorization determines permitted actions

Question 10

Why should a backend avoid returning detailed database errors directly to clients?

A. They may expose internal information and create a security risk

B. They always prevent JSON serialization

C. They make DNS caching impossible

D. They convert HTTPS into HTTP

Correct Answer: A. They may expose internal information and create a security risk