Chapter 2 — Website Architecture Patterns

Before choosing where to host, you need to understand what you're hosting. The architecture pattern determines your infrastructure requirements.

Static Sites

Pre-built HTML/CSS/JS files served as-is. No server-side processing per request.

• How it works: Build step generates HTML files → upload to web server or CDN → served directly
• Tools: Hugo, Jekyll, Eleventy, Astro (static mode), Next.js (export)
• Examples: Documentation sites, blogs, portfolios, landing pages
• Hosting: Cheapest option — CDN, S3+CloudFront, Netlify, GitHub Pages

# Example: Build and deploy a Hugo static site
hugo build                          # Generates ./public/ directory
aws s3 sync ./public s3://my-bucket --delete
aws cloudfront create-invalidation --distribution-id EXXX --paths "/*"

Server-Side Rendering (SSR)

Server generates HTML on every request. The traditional model (PHP, Rails, Django, Express with templates).

• How it works: Request → server processes → queries DB → renders HTML → sends response
• Tools: Next.js (SSR mode), Nuxt.js, Django, Rails, Laravel, Express+EJS
• Examples: E-commerce product pages, news sites, dashboards
• Hosting: Needs a running server process — VPS, PaaS, containers

Single-Page Applications (SPA)

One HTML file + JavaScript bundle. All rendering happens in the browser. Backend is a separate API.

• How it works: Browser loads JS bundle → JS fetches data from API → renders UI client-side
• Tools: React, Vue, Angular, Svelte
• Examples: Gmail, Trello, Figma
• Hosting: Static files (CDN) for frontend + API server for backend

JAMstack (JavaScript, APIs, Markup)

Pre-rendered static pages enhanced with JavaScript calling APIs at runtime. Best of both worlds.

• How it works: Build-time rendering + client-side API calls for dynamic content
• Tools: Next.js (ISR/SSG), Gatsby, Astro, Remix
• Examples: Marketing sites with dynamic forms, blogs with comments
• Hosting: CDN for pages + serverless functions or API for dynamic parts

Monolithic Architecture

Single deployable unit containing all functionality. Frontend, backend, and data access in one codebase.

• How it works: One application handles everything — routing, business logic, data, rendering
• Tools: Rails, Django, Laravel, Spring Boot, ASP.NET
• Pros: Simple to develop, test, deploy. One thing to monitor.
• Cons: Scales as a unit (can't scale just the hot path). Deployment = all or nothing.

Service-Oriented Architecture (SOA) / Microservices

Application split into independent services communicating over network (HTTP/gRPC/message queues).

• How it works: Each service owns its domain, data, and deployment lifecycle
• Tools: Any language per service. Kubernetes for orchestration. Service mesh (Istio, Linkerd).
• Pros: Independent scaling, independent deployment, technology diversity
• Cons: Network complexity, distributed debugging, operational overhead

Comparison Table