DEV Community: Moein Hosseini

🚀 Building a Dynamic Page Builder with Strapi, Next.js, and Varnish

Moein Hosseini — Sat, 04 Jul 2026 11:33:21 +0000

One of the biggest challenges when building modern websites is giving content editors the flexibility to create new pages without asking developers to deploy code every time.

For one of my recent projects, I designed a page builder architecture using Strapi, Next.js, and Varnish Cache that allows editors to build complete pages by combining reusable components inside the CMS.

The result is a scalable architecture where:

Developers build UI components once.
Editors create unlimited pages without code.
Pages remain fast thanks to HTTP caching.

In this article, I'll walk through the architecture and implementation.

Tech Stack

Strapi – Headless CMS
Next.js – Frontend Framework
Varnish – HTTP Cache
REST API – Communication between CMS and Frontend

Overall Architecture

                    Content Editors
                          │
                          ▼
                 ┌─────────────────┐
                 │     Strapi      │
                 │   Headless CMS  │
                 └─────────────────┘
                          │
                     REST API
                          │
                          ▼
              ┌──────────────────────┐
              │      Next.js         │
              │  Component Factory   │
              └──────────────────────┘
                          │
                  React Components
                          │
                          ▼
                    Rendered HTML
                          │
                          ▼
                 ┌─────────────────┐
                 │     Varnish     │
                 └─────────────────┘
                          │
                          ▼
                       Browser

Step 1 — Creating Pages in Strapi

Instead of creating a different collection type for every page (Home, About, Services, Contact, etc.), I created a single Pages collection.

Each entry represents one page.

Example:

Pages

Home
About
Contact
Pricing
Services
Blog
Landing Page

Each page contains:

Title
Slug
SEO fields
Dynamic Zone (Components)

The Dynamic Zone is where the magic happens.

Editors simply choose which components they want to display.

Step 2 — Creating Reusable Components

Instead of storing page content as one large HTML field, every section is represented by a reusable Strapi Component.

Examples:

Hero

Title
Subtitle
Image
Buttons

Features

Heading
Cards
Icons

Testimonials

Customer Name
Photo
Quote

FAQ

Question
Answer

The homepage might look like this:

Hero

↓

Feature Cards

↓

Statistics

↓

Testimonials

↓

FAQ

↓

Call To Action

While another page could be:

Hero

↓

Timeline

↓

Team

↓

Gallery

↓

Contact Form

No new code is required.

Editors simply drag and reorder components.

Step 3 — Fetching Pages

When a user opens

/about

Next.js requests the page from Strapi.

GET /api/pages?filters[slug][$eq]=about&populate=deep

The API returns something like:

{
  "title": "About",
  "slug": "about",
  "components": [
    {
      "__component": "sections.hero",
      "title": "About Us"
    },
    {
      "__component": "sections.team"
    },
    {
      "__component": "sections.faq"
    }
  ]
}

The important property is:

__component

It tells Next.js which React component should be rendered.

Step 4 — Building a Component Factory

This is the heart of the application.

Instead of creating page-specific rendering logic, we map Strapi components to React components.

import Hero from "@/components/Hero";
import FAQ from "@/components/FAQ";
import Team from "@/components/Team";
import Features from "@/components/Features";

const componentFactory = {
  "sections.hero": Hero,
  "sections.faq": FAQ,
  "sections.team": Team,
  "sections.features": Features,
};

export default componentFactory;

Now rendering becomes very simple.

import componentFactory from "./componentFactory";

export default function Page({ components }) {
  return (
    <>
      {components.map((component, index) => {
        const Component =
          componentFactory[component.__component];

        if (!Component) return null;

        return (
          <Component
            key={index}
            {...component}
          />
        );
      })}
    </>
  );
}

The frontend doesn't need to know whether it's rendering a Home page, an About page, or a Landing page.

It simply renders whatever Strapi returns.

Adding a New Component

Suppose the marketing team wants a new Pricing Table.

The process is simple.

In Strapi

Create a component:

Pricing Table

Fields:

Title
Plans
Prices
Features

In Next.js

Create

PricingTable.tsx

Then register it.

componentFactory["sections.pricing-table"] =
  PricingTable;

That's it.

Editors can immediately use it on every page.

No routing changes.

No page modifications.

No duplicated code.

Why Use the Factory Pattern?

Without the factory, your application quickly becomes difficult to maintain.

You end up writing code like:

if (page.slug === "home") {
   ...
}

if (page.slug === "about") {
   ...
}

if (page.slug === "pricing") {
   ...
}

As the number of pages grows, this becomes harder to maintain.

Instead, the factory delegates rendering to the correct component automatically.

Benefits include:

Cleaner code
Better separation of concerns
Easier testing
Better scalability
Less duplication

Performance with Varnish

Dynamic websites often generate many API requests.

To improve performance, I placed Varnish in front of the application.

Browser

↓

Varnish

↓

Next.js

↓

Strapi

If a page already exists in cache, Varnish immediately serves it.

Next.js and Strapi aren't even contacted.

Benefits:

Lower server load
Faster response time
Better Time To First Byte (TTFB)
Higher scalability
Reduced API requests

When editors publish new content, the cache is invalidated so users always receive fresh content.

Project Structure

My Next.js project looks something like this.

src/

├── app
├── components
│   ├── Hero
│   ├── FAQ
│   ├── Team
│   ├── Features
│   └── PricingTable
│
├── factory
│   └── componentFactory.ts
│
├── services
│   └── strapi.ts
│
└── types

This keeps everything organized as the number of components grows.

Advantages of This Architecture

✅ Editors can build pages without developers.

✅ Components are reusable.

✅ No hardcoded layouts.

✅ Easy to add new sections.

✅ Clean frontend architecture.

✅ Better SEO with Next.js.

✅ Excellent performance using Varnish.

✅ Scales well for enterprise applications.

Final Thoughts

Using Strapi Dynamic Zones together with a Component Factory in Next.js has been one of the most maintainable approaches I've used for CMS-driven websites.

Developers focus on creating reusable UI components, while content editors assemble those components into rich pages directly from the CMS. The frontend remains clean because it simply renders whatever Strapi returns, and Varnish ensures that dynamic content is delivered with excellent performance.

As the project grows, adding new page sections becomes a predictable process: create a Strapi component, build the corresponding React component, register it in the factory, and it's immediately available for editors to use. This separation of content, presentation, and caching makes the architecture flexible, scalable, and easy to maintain.

If you're building a content-heavy website with Next.js, I highly recommend considering this pattern. It has helped our team reduce development time, empower content editors, and deliver a fast user experience without sacrificing maintainability.

Happy coding! 🚀

Software Isn't a List of Tasks—It's a Network of Dependencies

Moein Hosseini — Sat, 04 Jul 2026 06:02:40 +0000

If you've worked on a software team long enough, you've probably experienced this.

Sprint planning goes well. The team breaks down a feature into tasks, estimates each one, assigns owners, and everyone leaves the meeting feeling confident.

A few days later, reality hits.

A backend change requires a database migration nobody considered.

The frontend team is blocked because an API isn't ready.

QA discovers edge cases that require additional implementation.

Another developer is waiting on work from someone in a different team.

Suddenly, the original sprint plan no longer reflects reality.

Sound familiar?

For a long time, I thought this was simply part of software development. But after seeing the same problems across multiple projects, I started wondering:

What if we're trying to manage software using the wrong model?

The Problem Isn't Estimation

One of the biggest discussions in Agile teams is estimation.

Should we estimate using story points?

Hours?

Planning Poker?

Velocity?

Yet, no matter which method we choose, estimates are often wrong.

Not because developers can't estimate.

But because you can't estimate work that you don't know exists yet.

Every project contains unknowns.

As development progresses, new requirements appear.

Hidden dependencies are discovered.

Technical limitations surface.

Someone realizes another service also needs changes.

A task that looked like "three days" suddenly becomes "two weeks."

The estimate didn't fail.

Our understanding of the work changed.

We Plan Tasks Instead of Understanding Features

Today's project management tools are excellent at tracking tasks.

A typical feature might look like this:

Login Feature

• Backend API
• Frontend UI
• Database
• Testing
• Documentation

This answers one question:

What needs to be done?

But software development is rarely about individual tasks.

It's about how those tasks interact.

Questions like these are much harder to answer:

Which task is blocking mine?
If my task is delayed, who else is affected?
Which developer depends on another developer?
How many teams are involved in this feature?
Are we actually close to finishing?

To answer those questions, we usually have to search through Jira tickets, comments, Slack conversations, and meetings.

The information exists.

It's just scattered.

Software Is a Network

A feature isn't a checklist.

It's a network.

Take something as simple as a login feature.

It might involve:

UI
Backend API
Authentication
Database
Session Management
Security
Monitoring
Testing
Deployment

None of these exist independently.

They depend on each other.

Instead of looking like this:

Login Feature

□ Backend
□ Frontend
□ Database
□ Tests

It actually looks more like this:

            Feature Map

             Feature
          /     |      \
       API     UI     Database
        |       |         |
     Auth    Forms     Migration
        \      |        /
          Integration Tests
                 |
             Deployment

This tells a completely different story.

Instead of seeing isolated tasks, we see relationships.

And relationships are what determine whether a project moves forward or becomes blocked.

Hidden Dependencies Cost More Than Bad Estimates

Most sprint failures aren't caused by someone estimating four days instead of five.

They're caused by discovering work too late.

For example:

"We forgot the migration."

"The mobile app also needs changes."

"Ops needs monitoring before deployment."

"This API change affects another team."

These aren't estimation errors.

They're visibility problems.

If these dependencies had been visible from the beginning, the plan would have been completely different.

A Missing Layer: Feature Maps

I believe we're missing something between planning and implementation.

Instead of representing a feature as a list of tickets, what if we represented it as a dependency graph?

I call this idea Feature Maps.

Each node represents a piece of work.

Each connection represents a dependency.

Every node knows:

Who owns it
What it depends on
What it blocks
Its current status
Its progress

Instead of opening twenty Jira tickets to understand a feature, the relationships become immediately visible.

The map becomes the feature.

The tickets become implementation details.

"Done" Should Mean More Than Closed Tickets

One thing I've noticed is that teams often say a feature is 90% done.

But what does that actually mean?

Imagine instead that completion is structural.

Login Feature

✅ UI
✅ Backend
✅ Database
✅ Authentication
✅ Testing
❌ Monitoring
❌ Documentation
❌ Deployment

The feature isn't complete until every required component is complete.

No assumptions.

No forgotten tasks.

No surprises before release.

Better Planning Starts With Better Visibility

This idea isn't about replacing Agile.

Agile helps teams organize work.

Issue trackers help teams execute work.

But neither gives us a complete picture of how the work connects.

When developers understand the full network of dependencies, something interesting happens.

Missing work is discovered earlier.

Blocked tasks become obvious.

Communication becomes easier.

Estimates naturally improve—not because people became better at guessing, but because the team has a better understanding of the problem they're solving.

Looking Forward

As software systems become larger, our planning tools haven't evolved much.

We still represent complex systems as flat lists of tickets.

But software isn't a list.

It's a living network of services, people, teams, and dependencies.

Maybe the next evolution of project management isn't another estimation technique.

Maybe it's changing how we visualize work.

Maybe before asking "How long will this take?", we should first ask:

"Do we actually understand everything this feature depends on?"

I'd love to hear your thoughts.

Do you think today's tools give enough visibility into dependencies, or is there room for a different way of planning software?

example:

A Real-World Example

Let's imagine a team is building a new User Authentication feature.

During sprint planning, the work is broken down into Jira tasks like this:

AUTH-101 - Create Login API          (Bob)
AUTH-102 - Build Login UI            (Carol)
AUTH-103 - Database Migration        (Alice)
AUTH-104 - JWT Authentication        (Bob)
AUTH-105 - QA Testing                (David)
AUTH-106 - Deployment                (Emma)

Everything looks organized.

Each task has an owner.

Each task has an estimate.

The sprint begins.

Three days later, reality starts to diverge from the plan.

Carol (Frontend) can't finish because the Login API isn't ready.
Bob discovers the API requires changes to the database schema.
Alice realizes the migration is more complex than expected.
David (QA) is waiting for both the frontend and backend.
Emma (DevOps) can't deploy until QA is complete.

Everyone starts asking questions:

"What's blocking the API?"
"Can I start my work yet?"
"Who's waiting on me?"
"How much of this feature is actually finished?"

The answers exist—but they're scattered across Jira comments, Slack messages, stand-up meetings, and people's memory.

The project isn't missing information.

It's missing visibility.

The Same Feature as a Feature Map

Now imagine the feature is represented as a living dependency graph instead of a flat list of tickets.

             Authentication Feature
                       │
        ┌──────────────┬──────────────┐
        │              │              │
 Database         Backend API     Frontend UI
(Alice)             (Bob)          (Carol)
    │                  │              │
 Migration       JWT Authentication   │
        └──────────────┼──────────────┘
                       │
                    QA Testing
                     (David)
                       │
                   Deployment
                     (Emma)

At a glance, everyone understands how the work is connected.

Carol knows she's waiting for Bob.

Bob knows he's blocked by Alice.

David knows QA cannot begin until both frontend and backend are complete.

Emma immediately sees why deployment hasn't started.

No searching through dozens of tickets.

No asking the same questions during every stand-up.

The Project Changes...

Now imagine Bob discovers something unexpected.

The authentication service also requires a Token Refresh Service that wasn't identified during planning.

Instead of creating another disconnected ticket, Bob adds it directly to the Feature Map.

                 Backend API
                      │
              JWT Authentication
                      │
            Token Refresh Service   🆕
                      │
                Session Manager

Immediately, the entire team can see:

A new task has appeared.
Bob owns it.
It blocks frontend integration.
QA will also be delayed.
The feature isn't as close to completion as everyone thought.

The team's understanding evolves the moment the project evolves.

Status Isn't Enough

Most project management tools track only one thing:

In Progress

But "In Progress" doesn't tell the team very much.

Instead, every node in the Feature Map could expose its health.

Task:
Database Migration

Owner:
Alice

Status:
In Progress

Health:
🟡 At Risk

Reason:
Unexpected schema conflicts with production data.

Blocks:
Backend API

Or:

Task:
Backend API

Owner:
Bob

Status:
Blocked

Reason:
Waiting for Database Migration.

Blocks:
Frontend UI
QA Testing

Or:

Task:
Frontend UI

Owner:
Carol

Status:
Ready

Health:
🟢 Healthy

Waiting For:
Backend API

Progress:
80%

Now the conversation during the daily stand-up changes.

Instead of saying:

"I'm still working on AUTH-102."

The update becomes:

"The Backend API is now blocked by a database issue. This affects Frontend, QA, and Deployment. I also discovered a new Token Refresh task that needs to be completed before authentication is finished."

That's much more valuable.

The Missing Piece Isn't Better Estimation

Software projects don't fail because developers estimate poorly.

They struggle because our understanding of the project changes every day, while our planning tools remain static.

A Feature Map becomes a living representation of the project.

It doesn't just show what people are working on.

It shows how everyone's work is connected, what's blocking progress, where new work has appeared, and how changes affect the entire team.

In my opinion, that's the missing layer between planning and implementation.