1.3. How Web Applications Work

Table of Contents

Big Picture: What Is a Web Application?

A web application is a program that runs on a remote server and is used through a web browser or some other client. When you open Gmail, GitHub, or an online shop in your browser, you are using a web application.

Very roughly, every web application involves three main pieces:

A client, usually your web browser, mobile app, or another service.
A server, which runs the backend code and talks to databases or other services.
A network between them, usually the internet.

When you interact with a web app, you are constantly sending small messages to the server and receiving answers back. These messages are HTTP requests and HTTP responses, which other chapters will explain in detail. Here we focus on the overall flow and where the backend fits.

Imagine you open an online bookstore, search for “Python,” click a book, add it to your cart, and then check out. Each of these steps causes a separate interaction between client and server. The server reads your request, runs the application logic, talks to databases, and sends back a response that the browser can display.

Backend development is about writing the server-side logic that makes this interaction work correctly, safely, and efficiently.

Static vs Interactive Web Pages

Before web applications were common, many websites were mostly static pages. A static page is like a digital poster. The content is written once and served almost unchanged to every visitor.

An interactive web application, on the other hand, behaves more like a program. It reacts differently based on user input, data, and state.

Consider these two scenarios.

A simple blog homepage that always shows the same text and images to every visitor is mostly static. The server simply reads an HTML file from disk and sends it to the browser.

An online banking dashboard is very dynamic. The server has to know which user is logged in, fetch that user’s account balances from a database, and then generate a page specifically for that user.

Many real websites combine both ideas. For example, a news site might have static assets like images and stylesheets, but the list of “latest articles” on the front page is generated on the fly from a database.

The Client Side: What the Browser Does

From the perspective of the browser, a web application is mainly a set of files:

HTML describes the structure of the page.
CSS describes how things should look.
JavaScript adds behavior in the browser.

When you visit https://example.com, the sequence might look like this:

The browser sends a request to the server asking for the main HTML page.
The server sends back an HTML document.
The browser parses the HTML and sees references to other files, for example CSS and JavaScript.
The browser sends more requests to fetch those files.
The browser runs the JavaScript code, which might send more requests to the server to fetch data without reloading the whole page.

Backend developers are concerned with what happens on the server every time one of those requests arrives, especially when the request is about data, like “Give me my list of tasks” or “Create a new order.”

Even if a page looks fancy, the browser can only display what the server provides, or what JavaScript fetches from backend APIs.

The Server Side: What the Backend Does

The backend side of a web application usually does several key jobs whenever a request arrives.

It receives a request and figures out which part of the application should handle it.
It reads information from the request, such as URL, headers, query parameters, or body.
It applies business logic, for example “user must be logged in to see this page,” “discounts apply to orders over $100,” or “only admins can delete users.”
It talks to a database to read or update data.
It often calls other services, for example payment gateways, email services, or external APIs.
It builds a response, either an HTML page or data in a format like JSON, and sends it back.

The backend is usually long-running server software that waits for incoming connections. A typical backend program starts, loads configuration, connects to the database, and then listens for incoming HTTP requests. Each request is processed, a response is created, and then the program goes back to listening again.

Imagine a simple task manager backend. When a request comes in to “create a task,” the backend might perform these steps:

Check if the user is authenticated.
Read the task title and description from the request.
Validate the input, for example title must not be empty.
Store the new task in the database with a status of “open.”
Send back a response with the data of the new task, including an ID.

Every interaction with the web app, such as marking a task as completed, listing tasks, or deleting a task, is another request that triggers similar backend logic.

The Request–Response Loop in Practice

Every click or action that needs the server involves a request and a response. Although another chapter will go into technical details of the request–response cycle, you should understand the high level here.

Assume you are on https://todo.example.com and you click “My Tasks.” Your browser:

Sends an HTTP request to GET /tasks on the server.
Waits for the server to answer.
Receives an HTTP response with some content.
Renders that content, perhaps as an HTML page or as data that JavaScript uses to update the page.

Now imagine you use a mobile app version of the same task manager. The app is still a client and it still talks to the backend over the network, often using the same endpoints. Instead of loading HTML, the app might receive data in JSON and then display it using native mobile UI components.

In both cases, the server cannot “push” the main data for your actions by itself. The client always has to ask first. In modern real-time apps there are techniques for more interactive behavior, but they still rely on defined communication patterns between client and server.

The key point is: a web application is a long sequence of small request–response exchanges between client and server, each one processed separately by the backend.

State: Remembering Users and Data

Web protocols like HTTP are stateless, which means the server treats each request as independent. There is no built-in memory of “this is the same user as before.” The browser simply sends a request, and the server answers.

However, real web applications need to remember things. For example:

Which user is logged in.
What is currently in a user’s shopping cart.
Which page of results a user is currently viewing.

Backend developers solve this problem using concepts like sessions, cookies, tokens, and database records. The main idea is that the server will store important information somewhere, such as in a database or in-memory store like Redis, and the client will send some identifier that lets the server find the right data.

Consider a shopping cart. When you add an item, the backend has to:

Identify you, often via a session cookie or token.
Look up or create your cart in the database.
Add the new item to that cart.
Save the updated cart.

If you refresh the page, the browser sends another request. There is no memory in the connection itself, but the server can reconstruct your cart by using the identifier the client sends again. This way, the application appears stateful to the user, even though each individual HTTP request is handled in isolation.

As a backend developer, you design how this state is represented, stored, updated, and retrieved safely and efficiently.

Rendering: HTML Pages vs JSON APIs

Web applications can send different kinds of responses. The two main styles are server-rendered HTML and JSON APIs.

In a server-rendered approach, the backend uses templates or some other mechanism to generate an HTML page. That HTML already contains the data and structure, and the browser can display it immediately. Classic web frameworks like Django or Ruby on Rails often use this style.

For example, a request to /tasks returns an HTML page that lists the user’s tasks as rows in a table. When the user adds a task, the browser sends a form submission to the server, and the server responds with a fully updated HTML page.

In a JSON API approach, the backend usually returns structured data rather than complete pages. A frontend application, written with JavaScript or a mobile framework, sends a request like GET /api/tasks, and the backend responds with data such as:

json

[
  {"id": 1, "title": "Learn Python", "completed": false},
  {"id": 2, "title": "Buy groceries", "completed": true}
]

The frontend then uses this data to draw the interface. If the user adds a task, the frontend sends a POST /api/tasks request with JSON in the body, and the backend answers with JSON describing the new task.

Both approaches are valid. Many modern applications combine them. For example, the initial page might be rendered on the server to load quickly, and then the page might use JavaScript and JSON APIs for dynamic updates.

From the backend perspective, the difference is mostly about what the response looks like. The essential work of authentication, authorization, business logic, and database access is the same.

How Databases Fit Into Web Applications

Almost every non-trivial web application uses a database. The backend uses the database to:

Store user accounts.
Keep track of orders, posts, comments, tasks, or any other domain objects.
Record events like login attempts, payments, notifications.
Handle relationships like “user X follows user Y.”

The backend acts as a gatekeeper for the database. Clients do not talk directly to the database. Instead, they talk to the backend, which enforces rules.

For example, consider a blog system with users and posts. Some possible interactions are:

A visitor requests a list of posts. The backend queries the database for published posts and returns them.
An authenticated user creates a new post. The backend checks the user’s identity, validates the content, and inserts a new row into the posts table.
A user tries to edit someone else’s post. The backend must check ownership. If they are not the owner, it should refuse the request.

The power of the backend is that you can centralize your logic here. If your blog has both a web frontend and a mobile app, both can use the same backend endpoints. The backend will consistently enforce the same rules and interact with the same database schema.

As you move further in this course, you will learn how to design schemas, write queries, and integrate databases safely with your backend code.

Authentication, Authorization, and Security in the Flow

Real web applications rarely allow anonymous users to do everything. The backend is responsible for controlling who can do what.

At a high level, the flow looks like this:

A user signs up or logs in by sending credentials to the backend.
The backend checks the credentials, for example by comparing a hashed password in the database.
If the login is successful, the backend returns some form of proof that the user is authenticated, such as a session cookie or a token.
On every later request, the client sends that proof back.
The backend checks the proof, loads the user’s identity, and then decides whether the requested action is allowed.

Inside the backend logic, you might write rules such as:

Only the owner of a task can delete it.
Only users with role “admin” can access certain endpoints.
Unauthenticated users can read public posts but cannot create or edit them.

Security is more than just login. You also need to protect against things like SQL injection, cross-site scripting, and insecure password storage. For now, it is enough to know that the backend is usually the place where these protections live.

When you think about how a web application works, always consider not just the happy path but also what should happen when users do something they are not allowed or send invalid data.

External Services and Integrations

Modern web applications rarely work in isolation. The backend often talks to other services on behalf of the client. Some examples:

Payment gateways process credit cards or other payment methods.
Email services send transactional emails like password resets or order confirmations.
SMS gateways send verification codes.
External APIs provide data such as weather, currency rates, or maps.

In the flow of a web application, this looks like:

The client sends a request to the backend, for example “place an order.”
The backend validates the order, calculates totals, and checks inventory.
The backend calls a payment gateway API to charge the user.
If the payment is successful, the backend updates the database and maybe sends a confirmation email via another external service.
The backend finally sends a response back to the client saying “order completed” together with some details.

The client does not need to know how the payment gateway or email provider works. It only communicates with your backend, which hides all that complexity. This is one of the strengths of backend design. You can change how you implement payments internally, and as long as your API stays the same, the clients do not have to change.

Performance and Scaling Basics in Web Applications

When few users are using a web application, the backend can handle each request quickly. As usage grows, you must think about performance and scalability.

From a high-level view, performance and scalability in web apps involve:

How fast the backend can handle each request.
How many requests it can handle at the same time.
How fast the database and external services respond.
How caching is used to avoid repeated expensive work.

Some strategies that backend developers use include:

Optimizing queries to reduce database load.
Using caches to store frequently accessed data.
Adding more backend instances behind a load balancer so that multiple servers share the incoming traffic.
Making parts of the work asynchronous when possible, for example sending emails in the background instead of during the main request.

Although implementation details belong in later chapters, it is important to understand that at high traffic levels, the simple request–response cycle is not enough. You will also need systems that coordinate multiple servers, handle failures gracefully, and allow you to update the application without downtime.

Even in a small application, it is valuable to design the backend logic in a way that can scale later. That includes clean separation of responsibilities, clear APIs, and careful database design.

Putting It All Together: A Simple End-to-End Example

Consider a simple web application: an online note-taking service.

A new user visits https://notes.example.com. The browser sends a request and receives a server-rendered HTML page with a “Sign up” form.

The user fills out their email and password and clicks “Sign up.” The browser sends a request, for example POST /signup, with the form data. The backend:

Reads the data from the request.
Validates it, for example checks that the email is valid and the password meets the rules.
Hashes the password and saves a new user record in the database.
Creates a session for the user so that they are now considered logged in.
Sends back a response that sets a session cookie and redirects the user to /notes.

The browser follows the redirect and sends a request to /notes, including the session cookie. The backend:

Reads the cookie and uses it to identify the logged-in user.
Queries the database for notes that belong to that user.
Renders an HTML page listing the notes, or returns JSON if this is a single-page application.
Sends the response.

Later, the user adds a new note. If the page is traditional, a form submission might reload the whole page. If it is more modern, JavaScript might send a POST /api/notes request in the background. The backend:

Checks the user identity again using the session or a token.
Reads the note content from the request body.
Validates and saves the new note in the database.
Responds with either updated HTML or JSON describing the new note.

Meanwhile, an asynchronous worker might send a “Welcome” email, and metrics might record that a new note was created.

All of this is the web application at work. The frontend provides the interface, the backend manages logic and data, and the network connects them through a series of requests and responses.

As you proceed through this course, you will learn to implement each piece of this flow, from handling HTTP requests, working with databases, defining APIs, securing your backend, to deploying real-world web applications.