Lesson 16: Building for the Web

Forms are the original input mechanism of the web. When you submit a login form, a search box, a registration page — you're triggering a form submission. Let's trace what actually happens.

HTML Form Anatomy

Every form has a few key attributes that control what happens when the user submits it.

<form action="/api/register" method="POST">
  <label for="username">Username</label>
  <input type="text" id="username" name="username" required minlength="3">

  <label for="email">Email</label>
  <input type="email" id="email" name="email" required>

  <label for="password">Password</label>
  <input type="password" id="password" name="password" required minlength="8">

  <button type="submit">Create Account</button>
</form>

What the Browser Sends — Raw HTTP

When you click Submit on a traditional form, the browser constructs an HTTP request that looks like this:

POST /api/register HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=blake&email=blake%40example.com&password=hunter2

The form fields become URL-encoded key=value pairs in the request body, joined by &. Special characters (like @) are percent-encoded (%40).

Modern Approach: fetch() + JSON

Most modern apps don't use raw form submissions. Instead, they intercept the submit event in JavaScript, collect the values, and send JSON via fetch(). This gives more control and returns a JSON response without a full page reload.

// Instead of a raw form submission, most modern apps use fetch
const formData = {
  username: document.getElementById('username').value,
  email: document.getElementById('email').value,
  password: document.getElementById('password').value
};

const response = await fetch('/api/register', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(formData)
});

Validation is checking that input meets requirements before processing it. There are two places validation can happen — and both are needed for different reasons.

Server Validation in Code

Here's a minimal server-side validation function — the kind you'd call inside a Netlify Function or Express handler before touching the database:

function validateRegistration(data) {
  const errors = [];

  if (!data.username || data.username.length < 3) {
    errors.push('Username must be at least 3 characters');
  }

  if (!data.email || !data.email.includes('@')) {
    errors.push('Valid email required');
  }

  if (!data.password || data.password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }

  return errors; // empty array = valid
}

Return an empty array → valid. Return a non-empty array → send a 400 response with the error list.

Luis's tutoring site uses Netlify Functions for the student login API. This is a real, working serverless backend you can look at — and the structure is worth understanding line by line.

The Full Handler — Annotated

// netlify/functions/auth.cjs

exports.handler = async function(event, context) {
  // 1. Only allow POST
  if (event.httpMethod !== 'POST') {
    return {
      statusCode: 405,
      body: JSON.stringify({ error: 'Method not allowed' })
    };
  }

  // 2. Parse the request body
  let data;
  try {
    data = JSON.parse(event.body);
  } catch (e) {
    return {
      statusCode: 400,
      body: JSON.stringify({ error: 'Invalid JSON' })
    };
  }

  // 3. Validate input
  const { username, password } = data;
  if (!username || !password) {
    return {
      statusCode: 400,
      body: JSON.stringify({ error: 'Username and password required' })
    };
  }

  // 4. Check credentials (simplified)
  if (username === 'blake' && password === process.env.BLAKE_PASSWORD) {
    return {
      statusCode: 200,
      body: JSON.stringify({ token: generateJWT(username) })
    };
  }

  return {
    statusCode: 401,
    body: JSON.stringify({ error: 'Invalid credentials' })
  };
};

As applications grow, mixing database code, business logic, and HTML in one file becomes unmanageable. MVC (Model-View-Controller) is the dominant pattern for organising server-side code. It gives each concern its own home.

Here's the complete picture — every component a production web application uses, from browser to database and back. This is the diagram you need to be able to describe in HSC written answers.

Each Component — Why It Exists

The HSC SE exam often asks you to explain web concepts in written answers worth 4–6 marks. Here's how the question types work, then three practice questions to try.

Question Type Patterns

Practice Questions

Explain the role of DNS in accessing a website, including the steps involved in a DNS lookup.

A web developer builds a registration form with client-side validation using JavaScript. Explain why this is insufficient and describe what additional measures are required.

Explain the difference between a static website and a dynamic website, giving an example of each.

Six topics across four lessons. Here's what you can now explain that you couldn't before Lesson 12 — and how it all maps together.