Building The Website | Architecture Overview

CMS & Next.js Frontend

When designing this site, I had two priorities: keep costs low and stay flexible for future growth. That led me to a static website architecture using Next.js↗ on the frontend, paired with PayloadCMS↗ for content management.

ChatGPT & AmazonQ: What’s the difference between static site generation and server-side rendering in Next.js

Static Site Generation (SSG) and Server-Side Rendering (SSR) both produce HTML for your pages—but they differ in when and how that HTML is generated.

Static Site Generation (SSG) happens at build time. Your content is fetched (e.g. from a CMS), the page is generated once, and the result is served via CDN to all users. It’s fast, cheap, and perfect for content that doesn’t change often—like blogs, documentation, or marketing pages.
Server-Side Rendering (SSR) happens at request time. Each time a user visits a page, the server builds the HTML dynamically—useful for content that changes frequently or depends on the user (like dashboards or search results), but slower and more resource-intensive.

Think of it like this:
SSG is precompiling your app—everything’s ready to go.
SSR is like handling a request per user, every time.

In this lab, we use SSG to keep things simple, fast, and cost-free inside the AWS Free Tier.

Why This Architecture?

Static = Cheap
The site is pre-rendered and served via CDN—so it runs fast and costs nothing by using the free-tier of a Content Delivery Network.
CMS = Scalable
A CMS separates content from code, making updates easier and future collaboration possible.
PayloadCMS = Something New
I’ve used Strapi before, but wanted to try something different. PayloadCMS allowed me to explore new patterns and tools.

Two Workflows to Know

There are two key workflows that come together to build this site:

1. Designing the Website

Next.js handles this. It’s responsible for:

Styling – layout, responsiveness, and component design
Page Structure – how pages are built and displayed
Rendering Logic – telling Next.js how to generate each page statically

This is where all the visual and interactive pieces of the site live.

2. Writing the Content

This is handled by PayloadCMS, which runs locally during development. It manages:

Content – blog posts, page bodies, headings, etc.
Schema – how content types are structured (e.g. pages, posts)
Relationships – linking pages, tags, authors, and other fields together

With PayloadCMS, content is decoupled from code, freeing the frontend to consume content via an API. A good overview of the concepts can be found here↗.

How it all connects

Here's a high-level view of the data and build flow:

Key notes:

The CMS runs only during development.
The database is stored as a file and committed to Git to simplify local dev.
At build time, Next.js pulls all content from PayloadCMS and generates static pages.

To help orient you, here are the key files in the frontend stack:

content.ts – Handles API calls to PayloadCMS to fetch content (e.g. pages, blog entries).
page.tsx – Converts content into JSX components. This is where we render things like rich text, banners, or column layouts from CMS data.
layout.tsx – Assembles the full page using the components from page.tsx, wrapping everything in site-wide structure like headers and footers.

Note: JSX components can (and should) comprise smaller subcomponents. For example, a Columns block might be built from several Card or ImageText components. Keeping things modular makes it easier to maintain and reuse.

Let's start by getting a PayloadCMS and next.js project running using the scaffolding processes provided by both platforms.