Static Site and Full-Stack Architecture

Build the mental model

Two architecture patterns come up constantly once a project moves from writing individual features to describing a whole system, and both of them are built entirely from pieces this course has already covered individually.

Seeing them assembled into a labeled diagram is the point of this lesson: naming how DNS, CDNs, frontends, backends, and databases combine into recognizable, repeatable shapes.

Static website architecture is the simpler of the two. A user's request goes through DNS to find the right server, reaches a CDN that has already cached the site's HTML, CSS, JavaScript, and image files, and the CDN serves those files directly with no server-side computation happening per request.

There is no database and no backend logic running to build the response, because the content is identical for every visitor and was already generated ahead of time. This fits portfolios, documentation sites, marketing pages, and any content that doesn't need to be computed freshly for each individual visitor.

Full-stack architecture adds the pieces static architecture leaves out. A user's browser loads a frontend, which talks to a backend over an API, and that backend reads from and writes to a database to build responses that can differ per user, per request, or per moment.

This is the shape behind login systems, personalized content, user-generated data, and anything that needs to remember state between visits.

Most real systems are not choosing between these two forever, they are choosing which one fits the specific piece of the product being built right now, and a single company can use both patterns for different parts of the same product.

text

STATIC SITE vs FULL-STACK ARCHITECTURE
--------------------------------------
STATIC SITE vs FULL-STACK ARCHITECTURE
------------------------------------------
STATIC WEBSITE ARCHITECTURE
  User -> DNS -> CDN -> HTML / CSS / JS / Images
  (no backend, no database -- same for everyone)

FULL-STACK ARCHITECTURE
  User -> Browser -> Frontend -> Backend/API -> Database
  (per-user, per-request, dynamic responses)

Connect it to a real scenario

A small business owner needs a five-page website: home, about, services, gallery, and a contact form that emails submissions.

Because the content is the same for every single visitor and doesn't need a database to compute anything, this is a clean fit for static website architecture, DNS routes to a CDN, and the CDN serves the pre-built files directly, which also keeps hosting costs low and page loads fast worldwide.

Compare that to a team building a project management tool where users log in, create their own boards, invite teammates, and see updates specific to their account.

None of that content can be baked into static files ahead of time, since it is different for every user and changes constantly, so this needs full-stack architecture: a frontend that talks to a backend API, and a backend that reads and writes a database per request.

A useful habit is running through three quick questions before defaulting to the more complex option: does this need a database at all, does it need individual user accounts, and is the content basically fixed once published? Two or three no answers usually points toward static architecture being sufficient, at least as a starting point.

Static website architecture serves pre-built files from a CDN with no backend or database, fitting content that's the same for every visitor.
Full-stack architecture adds a backend and database so responses can differ per user, per request, or per moment.
These two patterns are made entirely of pieces covered earlier in this course, now shown assembled into recognizable system shapes.

Try the working example

javascript

function recommendArchitecture({ needsDatabase, needsUserAccounts, contentIsFixed }) {
  if (!needsDatabase && !needsUserAccounts && contentIsFixed) {
    return "Static Website Architecture";
  }
  return "Full-Stack Architecture";
}

const projects = [
  { name: "Small business portfolio site", needsDatabase: false, needsUserAccounts: false, contentIsFixed: true },
  { name: "Project management SaaS tool", needsDatabase: true, needsUserAccounts: true, contentIsFixed: false },
  { name: "Company documentation site", needsDatabase: false, needsUserAccounts: false, contentIsFixed: true },
];

for (const project of projects) {
  console.log(`${project.name}: ${recommendArchitecture(project)}`);
}

You should see

It prints: Small business portfolio site -> Static Website Architecture, Project management SaaS tool -> Full-Stack Architecture, Company documentation site -> Static Website Architecture.

5-minute try-it

List five websites or apps you use. For each, decide if it fits static website architecture or full-stack architecture, based on whether it needs a database, user accounts, and whether the content is fixed.

One important caution

Defaulting to full-stack architecture out of habit even for content that never changes per visitor — that adds unnecessary server cost and complexity.

Assuming static architecture can never have any dynamic behavior — client-side JavaScript can still add interactivity on top of static files.

Wikipedia — Web application — How the Web Works