Full-Stack and Web Development: Foundations

Every time you open a web page, a short chain of events runs in about a second. Your browser looks up an address, sends a request, receives files and turns them into the page you see. Knowing that chain is useful even if you never write code. It helps you describe a problem precisely, ask a developer the right question and understand why a site is slow or down.

This chapter covers three ideas. First, what actually happens between typing an address and seeing a page. Second, the roles of browsers, servers and hosting. Third, how the front end and back end of an application divide the work and talk to each other. By the end you will be able to sketch how any website works.

Emma, a marketing coordinator at a charity in Manchester, types the charity's web address into her browser and waits. Nothing loads. Her first instinct is to message the developer: "the website is broken". If she knows the steps behind a page load, she can say which step failed.

Computers on the internet find each other by IP address, a number such as 192.0.2.172. People prefer names. The Domain Name System (DNS) works as the internet's address book. When you type a domain name, your browser asks a DNS resolver which IP address belongs to it.

With the IP address in hand, the browser connects to the server and sends an HTTP request. The request states a method (GET to read, POST to send data), a path and some headers. The server sends back a response with a status code, headers and a body, usually HTML.

The HTTP standard groups status codes into five classes: 1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error. A 404 means nothing exists at that path. A 500 means the server failed.

Emma opens her browser's developer tools and checks the Network tab on a slow page. The DNS lookup took 30 milliseconds, the connection 50, the server took 900 to start replying and the download took 120. Total: 30 + 50 + 900 + 120 = 1,100 milliseconds. The server step is 900 of 1,100, about 82 per cent of the wait. Now she can tell the developer the server is slow, not DNS and not her Wi-Fi.

Common mistake: treating every failure as "the site is down". A DNS error, a 404 on one page and a 500 from the server are three different problems with different owners. Note the exact message and status code before you report anything.

A browser such as Chrome, Firefox, Safari or Edge is a client. It sends requests, receives files and turns them into a page. It parses the HTML into a tree of elements called the DOM, applies CSS to style it and runs JavaScript, which can change it. Then it lays the page out and paints it on screen. It also builds an accessibility tree so screen readers can use the page. The same files can look slightly different in different browsers, which is why developers test in more than one.

A server is a computer that waits for requests and answers them. It runs software that listens for HTTP requests and returns files or generated pages. Hosting is where that server lives and who looks after it. The main options are:

Many organisations combine these. A company might keep its marketing site on static hosting, run its customer portal on a cloud platform and put a CDN in front of both. The choice depends on how often the site changes, how many people use it and who in the team can maintain it.

Daniel, an operations analyst at a logistics firm in Toronto, hears that customers in Australia find the tracking page slow. The page weighs 3 MB, mostly large photos. With 20,000 visits a month, the server sends 3 x 20,000 = 60,000 MB, about 60 GB, every month. After compressing the images, the page weighs 1.2 MB: 1.2 x 20,000 = 24,000 MB, or 24 GB. That is 60 per cent less data. Serving the images from a CDN also means a visitor in Sydney downloads them from a nearby server instead of one in Canada.

Common mistake: assuming a bigger server fixes every slow page. Often the server replies quickly and the browser then spends seconds downloading heavy images and scripts. Check what the browser is waiting for before you add server power.

The front end is everything that runs in the browser: the HTML structure, the CSS styling and the JavaScript that responds to clicks. The back end runs on the server. It checks who you are, applies business rules, reads and writes the database and sends back results. A simple brochure site can be all front end. Most tools you use at work, such as a booking system or an expenses app, need both. In job adverts you will see front-end developers, back-end developers and full-stack developers, who work across both halves.

The front end asks the back end for data through an API (application programming interface), a set of agreed addresses and formats. Think of it as a menu: the front end can only order what the back end has published, in the format it expects. The request is ordinary HTTP. The answer is usually JSON, a lightweight text format of names and values that both sides can read. Because JavaScript can fetch JSON in the background, the page can update one part of the screen without reloading everything.

Sara, a product analyst at a fintech start-up in Pune, wants to know why the balance on the app's dashboard sometimes shows zero. She traces one click from start to finish:

Sara opens the Network tab during a slow moment and compares the response with the screen. She finds that when the database is slow, the back end gives up and returns a 500 error. The front end ignores the error and shows its default value of zero. Before the fix, a customer with 15,250 rupees sees 0. After the fix, the front end checks the status code and shows "Balance unavailable, please try again". The data was never wrong. The display was.

Common mistake: assuming a wrong number on screen means wrong data in the database. The data may be correct and the front end may be handling an error badly, or the reverse. Look at the actual request and response before you decide which side to fix.

Good diagnosis follows the path a request takes. Start in the browser, because the Network tab shows every request, its status code and its timing. If one API call fails while the page itself loads, the front end is probably fine and the back end needs attention. Then check the server logs for that request. Report what failed, the evidence and the likely owner. That habit saves time whether you write code or not.