Front End, Back End, Databases, APIs, and the Roles of HTML, CSS, and JavaScript

1. Front end: the part delivered for the user

The front end is the part of a website or web application delivered to and used through the user’s browser.

Front-end responsibilities commonly include:

• presenting content and controls;
• creating a logical page structure;
• applying visual design and responsive layout;
• responding to supported user interactions;
• collecting form input;
• sending requests to services;
• presenting success, error, empty, and loading states.

The front end is not automatically trusted. A user can inspect or alter content and code delivered to their own browser. Therefore, important rules must also be enforced by a trusted server.

For example, a browser interface can prevent a quantity field from showing a negative value, but the server must still reject an invalid order. Client-side checks improve the experience; they do not replace server-side validation.

2. Back end: trusted processing outside the page

The back end is the server-side part of a system that receives requests, applies application rules, communicates with storage or other services, and returns responses.

Back-end responsibilities might include:

• verifying identity and permissions;
• checking whether stock is available;
• calculating a price according to trusted rules;
• creating an order;
• requesting payment from a payment provider;
• retrieving a customer’s allowed records;
• returning an appropriate response or error.

The back end is not one particular programming language. JavaScript can run on a server, but many other languages can also be used. Similarly, a server can generate HTML or return data that browser code later uses.

Do not equate these terms:

• front end does not mean “HTML only”;
• back end does not mean “database”;
• server does not necessarily mean one physical computer;
• dynamic does not necessarily mean “JavaScript in the browser.”

3. Database: organised persistent data

A database is an organised collection of data managed so that a system can store, retrieve, and change information.

In an online bookshop, a database might hold:

• product identifiers, titles, and prices;
• stock counts;
• customer accounts;
• order records;
• delivery addresses;
• payment references-but not raw payment secrets placed in an HTML page.

Many relational databases organise data into tables containing rows and columns. Other database models exist, so “database” does not always mean a spreadsheet-like table.

A database is normally accessed through trusted application code, not exposed directly to an arbitrary browser page. The back end decides what operations are allowed and what data a particular user may receive.

4. API: a defined way for software parts to communicate

API means application programming interface. An API defines how one software component can request data or an operation from another component.

In a web system, an API may define:

• the address to which a request is sent;
• the HTTP method or operation;
• the expected request data;
• the response format;
• possible success and error outcomes;
• authentication or permission requirements.

For example, a bookshop front end might send a request that conceptually means:

Give me the current public details for product 42.

The service might return data containing the product’s title, price, and stock status.

An API is not necessarily a public service, and it is not automatically safe. Its implementation must validate requests, protect restricted data, and enforce permissions.

The Fetch Standard defines the web platform’s request, response, and fetching concepts. In this course, you only need the high-level model for now: a request goes out and a response comes back. HTTP details belong to Lesson 1.4.

5. HTML, CSS, and JavaScript have different primary roles

HTML: content and meaning

HTML describes a document’s content and structure. It identifies meaningful parts such as headings, paragraphs, navigation, lists, buttons, images, tables, and forms.

HTML answers questions such as:

• What is the main heading?
• Which text is a paragraph?
• Which control submits a form?
• What is navigation?
• What information belongs together?

HTML is not merely “the skeleton” in a visual sense. Its meaning supports browsers, search systems, assistive technologies, and other software that interprets documents.

CSS: presentation

CSS describes how structured documents are presented. It controls matters such as:

• colour;
• spacing;
• typography;
• borders and backgrounds;
• page and component layout;
• adaptation to available space and user preferences;
• transitions and animation.

CSS normally does not change the underlying meaning expressed by HTML. A heading styled to look small is still a heading; an ordinary paragraph styled to look large does not become a real heading.

JavaScript: scripting and programmable behaviour

JavaScript is the commonly used name for the language standardised as ECMAScript in web browsers. It can run logic, respond to events, modify a document, validate input for user convenience, and request data.

Examples include:

• updating search results without loading a completely new page;
• opening a custom interaction when native HTML is insufficient;
• calculating a preview;
• requesting current account information;
• changing the document in response to user actions.

JavaScript is not required for every website. Native HTML and CSS should be used for the structure, presentation, and interactions they already support. When a requirement genuinely needs program logic, JavaScript may be appropriate.

JavaScript can also run outside the browser, including on servers. Therefore, “JavaScript” and “front end” are not synonyms.

6. Follow one book-order request

Imagine a customer chooses one book and submits an order.

Step 1 -Front end presents the interface

HTML provides the form and its meaningful controls. CSS makes the interface readable and responsive. Optional JavaScript may improve the interaction, but the form’s important data still needs trusted processing.

Step 2 -Browser sends a request

The browser sends order information to an address handled by the shop’s server or API.

Step 3 -Back end validates the request

The back end checks matters such as:

• whether the product exists;
• whether the quantity is allowed;
• whether stock is available;
• whether the user may perform the action;
• whether the price comes from trusted current data.

It must not trust a price merely because that price appeared in the browser.

Step 4 -Back end uses data services

The application reads or updates the database and may communicate with another service, such as a payment provider.

Step 5 -Server returns a response

The response might confirm success, report a validation problem, require another step, or report a temporary failure.

Step 6 -Front end presents the outcome

The browser displays the result in a form the user can understand and operate.

This sequence is simplified. Real systems may use several services, queues, caches, and security layers. The simplification is appropriate here because the goal is to understand responsibilities, not to design a production commerce platform.

7. Guided observation: the system map

Folder structure

lesson-1-2-bookshop-map/
├── index.html
└── styles.css

Starting files

index.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Online Bookshop System Map</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <main>
      <h1>Online bookshop system map</h1>
      <p>This page explains responsibilities. It is not a working shop.</p>

      <section>
        <h2>1. Browser and front end</h2>
        <ul>
          <li>HTML gives content and controls their meaning.</li>
          <li>CSS controls presentation and responsive layout.</li>
          <li>Optional JavaScript can provide additional programmed behaviour.</li>
        </ul>
      </section>

      <section>
        <h2>2. API boundary</h2>
        <p>Defines how the front end requests permitted data or operations.</p>
      </section>

      <section>
        <h2>3. Back end</h2>
        <ul>
          <li>Validates trusted business rules.</li>
          <li>Checks identity and permissions.</li>
          <li>Coordinates the order process.</li>
        </ul>
      </section>

      <section>
        <h2>4. Database</h2>
        <p>Stores organised product, account, and order data.</p>
      </section>

      <section>
        <h2>Requirement plan</h2>
        <table>
          <thead>
            <tr>
              <th scope="col">Requirement</th>
              <th scope="col">Parts needed</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>Show the public shop description</td>
              <td>HTML and CSS; it may be statically delivered</td>
            </tr>
            <tr>
              <td>Complete a secure purchase</td>
              <td>Front end, API, back end, data storage, and payment service</td>
            </tr>
          </tbody>
        </table>
      </section>
    </main>
  </body>
</html>

styles.css

body {
  margin: 0;
  background: #eef3f8;
  color: #17212b;
  font-family: Arial, sans-serif;
  line-height: 1.6;
}

main {
  max-width: 52rem;
  margin: 0 auto;
  padding: 2rem 1rem 4rem;
}

section {
  margin-block: 1rem;
  padding: 1rem;
  background: #ffffff;
  border: 1px solid #c7d3df;
}

h1,
h2 {
  line-height: 1.25;
}

table {
  width: 100%;
  border-collapse: collapse;
}

th,
td {
  padding: 0.75rem;
  border: 1px solid #9cabb9;
  text-align: left;
  vertical-align: top;
}

th {
  background: #dce8f2;
}

• The first four sections follow the system path in a sensible reading order.
• The final table maps a requirement to the parts that would be responsible for it.
• HTML stores the explanatory content and relationships.
• CSS presents the information but does not implement an API, back end, or database.
• There is no JavaScript because this explanatory page requires no programmed behaviour.

Meaningful blocks

Individual tags and CSS declarations remain a preview. Tables are taught in Module 6; CSS begins in Module 7.

8. Add the new requirement

Add this requirement to the table:

Show the signed-in customer’s previous orders.

Complete solution

Add the following row inside the table body:

<tr>
  <td>Show the signed-in customer's previous orders</td>
  <td>Front end, API, back end, authentication and permissions, and database</td>
</tr>

Why this solution is correct

• The front end presents the order history.
• The API defines the permitted request and response.
• The back end checks identity and access.
• Authentication and permissions ensure that one customer does not receive another customer’s records.
• The database supplies stored order data.
• HTML and CSS alone cannot securely identify the customer or protect the records.

9. Browser support and fallback information

The demonstration relies on basic document, list, and table features. Its information remains understandable without CSS because the HTML source order and text carry the meaning.

No API request is actually made, so there is no network or JavaScript compatibility claim to test. Fetching is introduced conceptually from the current Fetch Standard; browser programming with fetch() belongs outside this course’s HTML/CSS core.

10. Accessibility and responsive-design requirements

The supplied demonstration:

• uses headings to make the system sequence discoverable;
• keeps visual and reading order the same;
• identifies table headers rather than relying on bold appearance alone;
• allows text to wrap;
• does not use colour as the only way to distinguish a system part;
• remains meaningful when CSS is unavailable;
• avoids interaction that would require a mouse or JavaScript.

Do not interpret these features as proof of full accessibility. The complete audit process comes later.

11. Common mistakes and debugging process

Mistake 1 -Saying the front end is only visual design

The front end includes document meaning, controls, content states, user input, and communication with services—not only colour and layout.

Mistake 2 -Using CSS to imply a different meaning

Presentation cannot replace correct HTML. A large bold paragraph is not automatically a heading.

Mistake 3 -Trusting browser data

Anything sent by a browser must be validated by the server before a trusted action occurs.

Mistake 4 -Calling the database the back end

The database stores and manages data. Back-end application code applies rules and controls access to that data.

Mistake 5 -Calling every server endpoint an API without context

Use “API” when discussing a defined software interface. A server can also return complete HTML documents or static files.

If the demonstration does not display correctly

1. Confirm the filenames and folder structure match the example.
2. Save both files.
3. Open index.html rather than styles.css.
4. If content appears without styling, check that styles.css is beside index.html.
5. If the new row appears outside the table, restore the starting file and place it inside <tbody>…</tbody>.
6. If these instructions are unfamiliar, wait for the editing workflow in Lessons 1.5–1.6; the architecture concepts can still be completed now.

12. Independent exercise

For each requirement, identify all necessary system parts from this list:

• HTML;
• CSS;
• browser JavaScript;
• API;
• back end;
• database;
• external service.

More than one answer may be correct. State when the information is insufficient.

1. Present a stored privacy-policy page with readable typography.
2. Show a signed-in user’s current delivery address.
3. Change a button’s colour while the pointer is over it.
4. Charge a payment card securely.
5. Filter a list already present in the browser without requesting new data.
6. Save a new delivery address permanently.

13. Tested solution to the exercise

1. HTML and CSS. HTML holds the policy’s content and structure; CSS controls readable presentation. It could be statically delivered.
2. HTML, CSS, API, back end, and database. Authentication and permission enforcement are also required. Browser JavaScript may be used, but the description does not prove it is required because the server could return a complete page.
3. CSS. A supported pointer-state style does not require JavaScript. Keyboard-visible focus would also need a suitable style; hover alone must not carry essential information.
4. Front end plus trusted back end and an external payment service, normally connected through defined APIs. HTML/CSS can present the interface but cannot perform secure payment processing alone.
5. HTML, CSS, and browser JavaScript. The list and its meaning are HTML, presentation is CSS, and the requested programmed filtering is browser behaviour. This goes beyond the core exercises in this HTML/CSS course.
6. Front end, API, back end, and database. The server must validate the input and the user’s permission before storing it. JavaScript is optional unless the required interaction specifically depends on it.

The answers were checked for role separation and for the security boundary described in the lesson. No claim is made that these short descriptions determine a production architecture.