Web Information Technology

This page is, fittingly, a web page — so it's a chance to explain the thing you're using to read it. The web can feel like magic, but underneath it's a small set of clear ideas: a conversation between two computers, a protocol for that conversation, and three languages that build what you see. Understand those and the whole stack stops being mysterious.

It's also my strongest applied subject from Melbourne, and the foundation under the data layer that every dashboard, API, and app — including this site — is built on. Here's the web from the ground up.

The web is request and response

Everything on the web is a conversation between a client (your browser) and a server (a computer holding the website). The client asks, the server answers — that single request-response cycle is the heartbeat of the entire web. Type an address and hit enter, and a remarkable amount happens in a fraction of a second:

DNS lookup — the human-friendly name (rin.contact) is translated into a numeric IP address, the web's equivalent of a phone number.
Request — your browser opens a connection and sends an HTTP request: "please give me this page."
Server work — the server processes it, perhaps querying a database, and builds a response.
Response — it sends back the content (HTML, data, an image) with a status code, and your browser renders it.

The request-response round-trip. A click becomes a DNS lookup, an HTTP request to the server, optional database work, and a response the browser renders. Every page load is this loop.

HTTP: the protocol

HTTP (HyperText Transfer Protocol) is the agreed language of that conversation — the rules for how a request and response are formatted. A request names a method (the verb) and a path, plus headers:

GET /knowledge/ HTTP/1.1
Host: rin.contact
Accept: text/html

The methods map to the things you can do with a resource:

GET — read something (load a page). Should never change data.
POST — create something (submit a form).
PUT / PATCH — update something.
DELETE — remove something.

Every response carries a status code — the three-digit number that says how it went: 200 OK, 301/302 redirect, 404 not found, 403 forbidden, 500 server error. (If you've read the site's link checks, that's exactly what they verify.) Crucially, HTTP is stateless: each request stands alone, the server remembers nothing between them by default. Keeping you logged in across pages is a layer built on top — cookies and tokens that re-send your identity with every request.

The front-end triad

What the server sends back, for a page, is built from three languages with a clean division of labour — a separation worth internalising because it's the mental model for all front-end work:

HTML — the structure and content. Headings, paragraphs, lists, links; the skeleton. It's a tree of nested tags.
CSS — the presentation. Colours, fonts, spacing, layout — everything about how the structure looks.
JavaScript — the behaviour. The only one that runs as a program: it responds to clicks, fetches new data, and changes the page live.

<article>
  <h1>Web Information Technology</h1>
  <p>HTML is the structure.</p>
</article>

The browser parses that HTML into the DOM (Document Object Model) — a live, in-memory tree of objects representing the page. CSS styles the DOM; JavaScript reads and rewrites it. When a page updates without reloading, that's JavaScript mutating the DOM. Holding the structure/presentation/behaviour split clean is what keeps a site maintainable.

Client vs server

The deepest question in web architecture is where the work happens — on the server before the page is sent, or in the browser after. It's a genuine trade-off, not a settled answer:

Server-side rendering — the server builds the finished HTML and sends it ready to display. Fast first paint, and search engines see real content. (This page is rendered this way.)
Client-side rendering — the server sends a near-empty shell plus JavaScript, and the browser builds the page. Richer interactivity, but a slower first load and weaker for SEO if done naively.

Modern frameworks blend the two: render on the server for the first load, then "hydrate" so JavaScript takes over for interactivity. Knowing which code runs where — and that anything in the browser is visible and editable by the user, so it can never be trusted with secrets — is the core competency of web work.

APIs and JSON

Pages are for people; APIs are how programs talk to each other over the web. An API is a defined set of URLs (endpoints) a client can call to get or change data — the same HTTP methods, but the response is structured data rather than a page. The dominant style is REST: model everything as resources at clean URLs, and use the HTTP verbs on them (GET /users/42 reads user 42, DELETE /users/42 removes them).

The data that flows back is almost always JSON — a simple, human-readable format of key-value pairs that every language can parse:

{
  "name": "Rin Huang",
  "role": "Senior Data Analyst",
  "skills": ["Python", "SQL", "Next.js"]
}

This is the backbone of the modern web: a front-end fetches JSON from an API, a mobile app hits the same API, and a data pipeline pulls from it too. One well-designed API serves them all — which is exactly why "data on the web" and "analytics" increasingly share the same plumbing.

The full stack

Put it together and you have the full stack — the layers a request passes through, top to bottom:

Front-end (the browser) — HTML/CSS/JS, what the user sees and touches.
Back-end (the server) — the application logic: authentication, business rules, building responses, calling the database.
Database — where data persists, queried with SQL. The bottom of the stack.

A "full-stack" developer works across all three. The flow is always the same loop from section 01: the browser requests, the back-end runs logic and asks the database, and a response travels back up the stack to the screen. Every web application, however large, is variations on this theme.

Web security basics

The web is public, so a few security ideas are non-negotiable — and they're exactly the ones that matter when the data is sensitive:

HTTPS — HTTP encrypted with TLS, so traffic can't be read or tampered with in transit. The padlock. Non-optional today.
Same-origin policy — the browser stops a page from one site reading data from another, the fundamental wall between sites.
Never trust the client — anything sent from the browser can be faked, so the server must always re-validate. The classic attacks (SQL injection, cross-site scripting) all come from treating user input as trusted.

How this site works

A concrete example: the page you're reading. rin.contact is built with Next.js (a React framework). The content is written as components; Next renders them to HTML on the server for a fast, search-friendly first load, then hydrates so JavaScript handles the interactive bits — dark mode, the language toggle, navigation. The maths on the knowledge pages is rendered to HTML by KaTeX; the whole site deploys automatically when code is pushed, through a CI pipeline that lint-checks it first. Every concept on this page is doing its job right now to show you this one.