Module 5: How a Web Application Works — A Real-World Example

Module objective

See all the previous concepts in action through a concrete, complete example: a user's journey on a travel booking website.

Simple explanation

We've covered the building blocks (HTML, CSS, JS), the frontend/backend split, APIs, databases, HTTP... Now let's put it all together. Let's follow Marie, who wants to book a flight from Paris to Barcelona.

Step 1: Marie opens the website

Marie types www.travel-example.com into Chrome.

What happens behind the scenes:

graph LR
    A["Marie types the URL"] --> B["DNS translates the name into an IP address"]
    B --> C["The browser sends an HTTP request to the server"]
    C --> D["The server sends back the frontend (HTML + CSS + JS)"]
    D --> E["Chrome displays the homepage"]

• DNS translates www.travel-example.com into an IP address
• The browser sends an HTTPS request to the server
• The server sends back the HTML, CSS, and JavaScript files
• Chrome assembles everything and displays the page

Marie sees: a beautiful homepage with a search form.

Step 2: Marie searches for a flight

She fills out the form: Paris to Barcelona, June 15, 1 passenger. She clicks "Search."

What happens behind the scenes:

graph TD
    A["Marie clicks Search"] --> B["JavaScript retrieves the form data"]
    B --> C["Sends a request to the backend via the API"]
    C --> D["The backend queries the database"]
    D --> E["The database returns available flights"]
    E --> F["The backend also calls a partner airline's API"]
    F --> G["The backend combines the results"]
    G --> H["The results are sent to the frontend"]
    H --> I["JavaScript displays the flight list"]

• JavaScript (frontend) retrieves the form data
• It sends a request to the backend via an API
• The backend searches its database for available flights
• It also queries the APIs of partner airlines for more results
• It combines everything and sends the list back to the frontend
• JavaScript displays the results without reloading the entire page

Marie sees: a list of flights with schedules, prices, and airlines.

Step 3: Marie logs into her account

She clicks "Log in" and enters her email and password.

What happens behind the scenes:

• The frontend sends the email and password to the backend (via HTTPS, so it's encrypted)
• The backend checks its database to see if the account exists
• It compares the submitted password with the stored one (which is encrypted — even the site's employees can't read it)
• If everything checks out, the backend creates a session token (a temporary pass) and sends it to the frontend
• The frontend stores this token in a cookie
• With every subsequent request, the cookie is automatically sent to prove that Marie is logged in

Marie sees: "Welcome Marie!" at the top of the page.

Step 4: Marie books a flight

She chooses a flight for 89 euros and clicks "Book." She fills in her details and enters her credit card number.

What happens behind the scenes:

graph TD
    A["Marie clicks Pay"] --> B["The frontend sends the info to the backend"]
    B --> C["The backend calls the payment API (Stripe)"]
    C --> D{"Payment accepted?"}
    D -->|Yes| E["The backend saves the booking in the database"]
    D -->|No| F["The backend returns an error"]
    E --> G["The backend calls the email API to send confirmation"]
    G --> H["The frontend displays 'Booking confirmed!'"]
    F --> I["The frontend displays 'Payment declined, please try again'"]

• The frontend sends the data to the backend via HTTPS
• The backend doesn't process the payment itself — it calls the API of the payment service (like Stripe)
• Stripe verifies the card, processes the charge, and sends back a confirmation
• The backend saves the booking in the database
• It calls another API (email service) to send a confirmation email to Marie
• The frontend displays "Booking confirmed!"

Marie sees: a confirmation page with her booking number.

Step 5: Marie receives an email

A few seconds later, Marie receives an email with a summary of her booking and her ticket as a PDF.

What happened: the backend sent the information to an email service via its API, which automatically generated and sent the email.

Overview

graph TD
    subgraph Client["What Marie sees (Frontend)"]
        A[Homepage]
        B[Search results]
        C[Payment page]
        D[Confirmation]
    end
    subgraph Server["What Marie doesn't see (Backend)"]
        E[Application server]
        F[Database]
    end
    subgraph Services["External services (APIs)"]
        G[Airline APIs]
        H[Stripe payment API]
        I[Email sending API]
        J[Google Maps API]
    end
    A --> E
    E --> F
    E --> G
    E --> H
    E --> I
    B --> E
    C --> E
    E --> D

Concrete example

This same pattern is found everywhere:

Whether it's a small website or a tech giant, the principles are the same. What changes is the scale.

Metaphor

A web application works like a travel agency:

• The counter (frontend): this is where the customer sits, browses brochures, and makes their choices
• The agent (backend): they take the customer's request, check availability, book the flight, and process the payment
• The filing cabinets (database): all the information about customers, past bookings, and preferences
• The phone (API): the agent calls the airline, the hotel, the payment company — they don't do everything themselves, they coordinate
• The receipt (cookie): a slip given to the customer so they can come back and say "I already have a booking in progress"

Summary in 3 key points

1. A web application is an orchestra where frontend, backend, database, and APIs work together in fractions of a second
2. The backend doesn't do everything alone — it delegates to external APIs (payment, email, maps, etc.)
3. Every action you take on a website (clicking, searching, buying) triggers an invisible chain of requests and responses between multiple systems