Back to Blog

I made a blag!

I made a blag!

I was not satisfied with the cost and features of Wix, so I decided to see if I could make my own blog. Answer: Yes! This is it. I used AI code assistants to build it, but here's the architecture:

ARCHITECTURE OVERVIEW: HOW THIS SITE IS BUILT

This site is built using a modern “headless” web architecture. Instead of a single monolithic system that handles content, layout, and hosting all together, the site is split into two main parts: a backend content system and a frontend web application.

This approach makes the site faster, more flexible, and easier to evolve over time.

BACKEND ARCHITECTURE: CONTENT AND MEDIA

The backend is responsible for content creation, storage, and delivery. It does not control how pages look. Instead, it exposes content through an API.

At a high level, the backend includes:

  • A headless CMS (Strapi)
  • A relational database (PostgreSQL)
  • Object storage for media files (images and videos)

The CMS provides an admin interface where posts, tags, and media are created and edited. Content is stored in a database, while large assets like images and videos are stored in a separate object storage system. This keeps the database lightweight and efficient.

The CMS automatically exposes REST endpoints such as:

  • Fetching all blog posts
  • Fetching a single post by slug
  • Fetching tags and relationships
  • Fetching media metadata

Because the backend is API driven, it can support multiple frontends in the future, such as a website, a mobile app, or even other tools that consume the same content.

FRONTEND ARCHITECTURE: RENDERING AND USER EXPERIENCE

The frontend is a separate application built with a modern React framework (Next.js). Its job is to fetch content from the backend and turn it into fast, readable web pages.

Key characteristics of the frontend:

  • Server-rendered and statically generated pages
  • Component-based layout (header, footer, cards, pages)
  • Centralized data fetching from the CMS API
  • Styling handled entirely in code

Pages are generated ahead of time when possible, which means visitors receive fully rendered HTML instead of waiting for content to load in the browser. This improves performance, accessibility, and search engine visibility.

Dynamic routes are used for content-driven pages, such as individual blog posts. For example, a URL like:

/blog/how-i-make-my-videos

is generated automatically based on content stored in the CMS.

The frontend also includes custom rendering logic for rich content. For example, when a post contains a link to a video file, the frontend detects that link and renders it as an embedded video player instead of a simple hyperlink. This keeps content authoring simple while still producing rich layouts.

HOW CONTENT FLOWS THROUGH THE SYSTEM

The content pipeline looks like this:

  1. Content is created or edited in the CMS admin interface.
  2. Text is stored in the database, and media files are stored in object storage.
  3. The frontend fetches content via the CMS API.
  4. Pages are generated or revalidated automatically.
  5. Visitors receive fast, static pages with dynamic content.

This separation means content changes do not require frontend code changes, and frontend redesigns do not affect the content system.

DEPLOYMENT MODEL: CLOUD-NATIVE AND CONTAINERIZED

Both the frontend and backend are packaged as containers. This means they can run on any cloud platform that supports container execution.

A typical cloud deployment includes:

  • A container registry to store built images
  • A managed container runtime (such as Google Cloud Run)
  • A managed database service (such as PostgreSQL)
  • A managed object storage service for media

Each service runs independently:

  • The backend container handles API requests and admin access.
  • The frontend container serves the public website.
  • The database and storage services persist data outside the containers.

Because containers are stateless, scaling is automatic. The platform can start more instances when traffic increases and shut them down when traffic drops, without manual server management.

Configuration is handled through environment variables, which allows the same container image to run in development, staging, or production with different settings.

WHY THIS ARCHITECTURE WORKS WELL

This structure offers several advantages:

  • Performance: static pages load quickly and scale easily.
  • Flexibility: frontend and backend can evolve independently.
  • Portability: everything is containerized and cloud-agnostic.
  • Ownership: content and code are not locked into a proprietary platform.
  • Extensibility: new features can be added without re-architecting the system.

The result is a site that feels simple on the surface, but is built on a foundation that can grow with new ideas, new content, and new tools over time.

FINAL THOUGHTS

This architecture is intentionally modular. Each piece does one job well, and communicates through clear interfaces. Whether deployed on Google Cloud or another provider, the same design principles apply: separate concerns, automate infrastructure, and keep content independent from presentation.

That separation is what makes the system both powerful and enjoyable to work with.