HAP studying JAMstack architecture concepts

Station 1: JAMstack & Static Site Generators

Build-Time vs Runtime: A Mind-Blowing Discovery

I thought I needed PHP and MySQL to build a blog. Every tutorial I found talked about servers, databases, and backend code. When Prof. Teeters said "You can build it with just Markdown files," I thought she was joking!

"But where does the content come from?" I asked.

"From the file system," she said. "You write Markdown, Eleventy builds HTML, and you upload the HTML to a CDN."

"Wait—we don't generate pages when users visit?"

"Nope. We generate them ONCE, during the build. Then we serve the same HTML to millions of users."

My mind was blown. I'd been thinking about blogs completely wrong this whole time. Let me show you what I discovered about this thing called JAMstack... 🟠

What You'll Learn at This Station

HAP's Discovery: When I first heard "JAMstack," I thought it was about making jam. Seriously! Prof. Teeters laughed and explained it's an architecture pattern that changes how we think about building websites. Here are the three biggest concepts that rewired my brain: 🤯

🏗️ JAMstack Philosophy

J + A + M

JAMstack means JavaScript, APIs, and Markup. The key insight? Pre-render everything possible at build time. Dynamic features use APIs and client-side JavaScript, not server-side code running on every request.

⚡ Build-Time Magic

Once!

Instead of generating HTML when users visit (slow!), SSGs generate HTML when you run the build command (once!). The result? Lightning-fast page loads served from CDN edge servers worldwide.

🔒 The Security Win

No DB

No database means no SQL injection attacks. No server-side code means a smaller attack surface. Static sites are inherently more secure because there's simply less to attack!

HAP surrounded by tangled code with an 'oops' expression

HAP's Confession:

  • I tried to explain JAMstack and said "JavaScript, APIs, and Metadata." It's MARKUP, HAP! Grace Hopper, the lab's Precision AI, appeared and corrected me with perfect accuracy. 😳
  • I thought "static" meant the content couldn't change ever. But it changes at build time, just not at request time! Big difference.
  • I thought I needed to learn MySQL because I assumed every site needed a separate database. Then Prof. Teeters pointed at my content folder and said, "There's your data and the filesystem is the database."
  • I kept editing files inside the _site folder thinking that was my real project. One time I lost an important CSS color change three times in a row. Prof. Teeters needed to remind me that Eleventy regenerates that folder every build.

How Traditional Blogs Work (The Old Way)

Before I understood static sites, I thought every blog worked like WordPress. A user visits, the server does a bunch of work, and THEN they see the page. Here's what happens behind the scenes:

1. Browser Sends Request

User clicks a link, browser asks server for the page

2. Server Receives Request

Web server (Apache, Nginx) routes to PHP

3. PHP Executes Code

Server runs PHP to figure out what to show

4. Database Query

PHP asks MySQL for the post content

5. Template Rendering

PHP combines template + content into HTML

6. Response Sent

Server sends finished HTML back to browser

🟠 The Problem:

This happens for EVERY visitor, EVERY time! Even if the blog post hasn't changed in months, the server does all that work again. For a popular blog, that's thousands of database queries per minute—for content that never changes!

How Static Sites Work (The New Way)

Now here's what blew my mind. When someone visits my Eleventy blog, the server does almost nothing:

1. Browser Sends Request

User clicks a link

2. CDN Serves File

Edge server returns pre-built HTML file

3. Done!

No processing, no database, no waiting

HAP having a mind-blowing realization

🤯 The Revelation:

The HTML was built ONCE when I ran npm run build. Now it serves the exact same file to everyone, from edge servers around the world. I learned that an edge server is just a CDN server that's physically close to the user, so files load very fast. A user in Tokyo gets the same file as a user in New York—both served from servers near them.

Prof. Teeters put it this way: "Think of it like a printed book vs a live performance. A book is 'pre-rendered'—the content is fixed when it's printed. A live performance generates content in real-time. Static sites are like books: fast to distribute, consistent for everyone, and they never crash from too many readers!"

When to Use Static Sites

Prof. Teeters warned me: "Not everything should be static!" Here's how to know if a static site is right for your project:

✅ Use Static Sites When...

  • Content changes infrequently (blogs, docs, portfolios)
  • You want maximum speed
  • Security is critical
  • Budget is limited (free hosting!)
  • You want version control for content

🔄 Use Traditional CMS When...

  • Content changes constantly (news feeds, dashboards)
  • You need user accounts and login
  • You need real-time data
  • You need complex admin workflows
  • Non-technical editors need a GUI
HAP teaching at a blackboard with HTML code

🟠 HAP's Note:

Here's what Prof. Teeters taught me: Static doesn't mean "no dynamic features." You can add comments with Disqus, search with Algolia, forms with Netlify Forms, and authentication with Auth0—all through APIs. That's the "A" in JAMstack! The static part is just the initial HTML.

🎓 JAMstack & SSG Quick Reference

1

JAMstack

JavaScript + APIs + Markup architecture. Pre-render at build time, enhance with client-side JS and APIs.

2

SSG (Static Site Generator)

A tool that builds HTML at build time, not request time. Examples: Eleventy, Hugo, Jekyll, Gatsby.

3

CDN (Content Delivery Network)

Servers distributed worldwide that serve files from locations close to users. Edge servers = fast delivery.

4

Build Time vs Request Time

Build time = when you run the build command (once). Request time = when users visit (every time). Static sites do work at build time!

🎯 Challenge: Analyze Real Websites

Your Mission:

Think about three websites you use regularly. For each one, decide:

  1. Could this be a static site? Why or why not?
  2. What dynamic features would need APIs instead of server-side code?
  3. What would be the performance benefits of static generation?

💡 Hint:

Good candidates for static: blogs, documentation, portfolios, marketing sites, restaurant menus, event pages.

Need traditional/hybrid: social media feeds, email clients, banking dashboards, real-time collaboration tools.

See HAP's Analysis

Here's how I analyzed my favorite sites:

  1. Local butcher shop website — Perfect for static! Their menu, farm-to-table story, and hours rarely change. The order button or contact form could use an API, but the main site could be built once and served instantly from a CDN.
  2. Open-source project documentation site — Great candidate. The docs are versioned, updated occasionally, and most readers just browse pages. Search, comments, or issue-links can use APIs but the content itself works brilliantly as a static site.
  3. My favorite ukulele-music blog — Mostly static. The posts, song tabs, and instrument reviews don't change every second. If the blog adds user comments or video tutorials, those features could use APIs. But the main site could load at lightning speed and cost almost nothing to host.