How Web Applications Work

Understanding how web applications actually work—what happens from the moment you click a button to the moment something changes on your screen—helps you make better decisions about building one. This is plain-language explanation, not a computer science lecture.

The Basic Flow

When you use a web application, you're using software that runs on someone else's computers (servers) and displays in your browser. Your browser is the client. The server is someone else's computer in a data center somewhere. Here's what happens:

1. You click a button (e.g., "Submit order")
2. JavaScript in your browser intercepts the click. Instead of reloading the page (which is how web pages used to work), JavaScript says "I'll handle this."
3. Your browser sends a request to the server. This is called an API request. It says something like: "User 12345 is submitting an order with items A, B, and C."
4. The server receives the request. The server runs code that says "Is this user authenticated? Do they have permission to place orders? Are these items in stock?"
5. The server checks the database. The database is where all the data lives—user information, inventory, orders, everything. The server queries: "How many units of item A are in stock?"
6. The server sends back a response. It's typically JSON—a format that computers can understand. It might say: "Order created successfully. Order ID: 789." Or it might say "Error: Item out of stock."
7. Your browser receives the response. JavaScript on your browser reads it and updates the screen. You might see a confirmation message, and a new order appears in your order list.

All of this happens in milliseconds. You click the button, and almost instantly something changes on the screen.

What a Database Actually Is

A database is not a spreadsheet, even though people sometimes think of it that way. A database is an organized system for storing data that allows you to query it quickly and reliably.

Imagine you're managing a spreadsheet with 10 million rows (10 million customers). You want to find all customers in California who spent more than $1000 in the last 30 days. In a spreadsheet, you'd have to load all 10 million rows into memory—your computer would freeze. A database with proper indexes can answer that query in milliseconds because it's optimized for this kind of search.

Databases also enforce consistency. If you try to create an order for a customer that doesn't exist, the database rejects it. If two people try to modify the same record simultaneously, the database ensures one waits for the other. These guarantees are critical for business data.

The most common databases for custom applications are PostgreSQL and MySQL (both relational databases where data is organized in tables with relationships between them) and MongoDB (a document database that stores data as JSON-like documents). The choice usually depends on your data structure, not because one is universally better.

What an API Is

An API (Application Programming Interface) is the contract between the front-end and back-end. It says: "If you send me a request in this format, I'll send back a response in that format."

For example, an API might say: "To create an order, send a POST request to /api/orders with the customer ID and list of items. I'll respond with the order ID or an error message." The front-end doesn't need to know how the back-end creates the order internally—it just needs to know the format to send and what format it will receive.

APIs matter because they create a clear boundary. The front-end team can work on the user interface, and the back-end team can work on business logic. As long as both sides agree on the API contract, they don't have to coordinate constantly. This is why large teams can build applications—different teams can work on different parts independently.

Stateless vs. Stateful Requests

Modern web applications are stateless. Each request is independent. The server doesn't remember anything between requests—if you send the same request twice, you get the same response. This is different from older applications where the server maintained a long-lived connection and remembered everything about you.

Statelessness makes applications simpler and more scalable. If request #1 goes to server A and request #2 goes to server B, it doesn't matter—both servers can handle both requests the same way. This is how large applications handle millions of concurrent users—they spread requests across many servers.

But users expect the application to remember them. How does this work? The answer is tokens or session cookies. When you log in, the server says "OK, here's a token that proves you're logged in." Your browser stores the token and includes it in every subsequent request. The server says "This request includes a valid token for user 12345, so I'll process it." The token is the state, not the server connection.

Authentication and Authorization

Authentication is proving who you are. You enter your email and password, the server checks the database, and if they match, you're authenticated.

Authorization is determining what you're allowed to do. Once you're authenticated as user 12345, the application checks: "Is user 12345 allowed to view this order?" or "Is user 12345 an admin who can delete users?"

Modern applications use tokens for this. The most common is JWT (JSON Web Token). When you log in, the server generates a token that says "This token belongs to user 12345 and expires in 24 hours." Your browser stores it and includes it in every request. The server validates the token and the application knows who you are.

Why Web Apps Instead of Desktop or Mobile?

Most custom applications are web applications (run in a browser). Why?

Deployment is easy. You update the code on the server, and everyone sees the new version immediately. No need to distribute updates to thousands of computers.

Platform agnostic. A web app works on Windows, Mac, Linux, iPhone, Android—anywhere there's a browser.

Cost is lower. You only run code on servers you control. Users bring their own devices and browsers.

Real-time synchronization. If multiple people are working on the same data, a web app can show changes instantly.

Security is simpler. All the important code runs on servers you control. You can't necessarily prevent a determined attacker from messing with local code on a user's device.

Desktop and mobile applications make sense for specific use cases (offline-first applications, performance-critical tools, or apps that need deep OS integration). But for most custom applications, web is the default.

Scaling: From One Server to Many

When you first build an application, it runs on one server. As more users come, that server gets slower. How do you fix it?

Option 1: Make the server bigger. Run your code on a server with more CPU and memory. This works for a while.

Option 2: Use many servers. Run your code on 10 servers and put a load balancer in front that sends each request to the least-busy server. This lets you handle 10x the traffic.

Option 3: Cache frequently-accessed data. If the same data is requested 1000 times a day, cache it in Redis so you don't query the database every time.

Option 4: Optimize database queries. If a query takes 2 seconds, rewrite it to take 0.2 seconds. Now the server can handle 10x more requests.

Most successful applications use all four. They start on one server, and as they scale, they add more servers, cache, and optimization. This is why large tech companies have such complex infrastructure—they're optimizing for speed at massive scale.

For your first version, don't worry about scale. If you build it well, adding servers later is straightforward. The common mistake is building for impossible scale when you haven't found product-market fit yet.