A page-builder platform that turns a dashboard into publishing.

Problem

• Building and publishing pages usually means either a locked-in CMS or handing editors raw code, which trades control for speed and never both at the same time.
• The authoring surface, the data model, and the public template engine drift apart without a contract, so what the editor sees is not what visitors get.
• Published pages need to be consumed by arbitrary frontends, so the platform has to expose its content as data a client renders, not as pages only its own engine can draw.

Solution

I built CMS Page Builder as an admin dashboard and a frontend template consumer connected through a typed Hono.js API. Editors build pages through visual page management with drag-and-drop and a real-time preview. The layout is persisted as structured data, the API serves that data to the consumer via a typed contract, and the consumer renders whichever page the client asks for. A consuming frontend passes an API key to the API, and the API returns the structured page data scoped to that client, which the template consumer turns into the final page.

Architecture

• Admin dashboard: visual page management, drag-and-drop composition, and real-time preview while editing.
• Template engine: the frontend consumer that calls the API with an API key, receives the persisted layout as structured data, and renders the final pages.
• Typed API layer: Hono.js services with a shared contract between dashboard and consumer, scoped by the API key the client passes on every request.
• Structured data model: pages, sections, and customizable components stored as data, not as hand-edited code.
• Persistence: PostgreSQL through Prisma, so a saved layout is a durable, queryable record.

Key engineering challenges

• Drag-and-drop editing needs to feel immediate while the underlying layout stays valid, structured data, not a free-for-all DOM.
• Real-time preview has to reflect the edited structure without a full reload, so preview and saved state must share one contract.
• Customizable components mean the data model has to admit arbitrary per-component configuration without losing typed guarantees.
• The template consumer authenticates against the API with an API key, so the API has to scope every response to the key presented, keeping each consumer's delivered content correct and isolated.

Technical decisions

• A typed Hono.js API as the seam between authoring and publishing, instead of shared-memory shortcuts that itch when the two surfaces grow apart.
• Pages as structured data over saved HTML, so components, sections, and configurations stay portable and versionable.
• PostgreSQL as the source of truth through Prisma, keeping the editor, the preview, and the public engine on one state.
• API-key access for the template consumer: a client passes its key to the API, which serves only the data that client is allowed to render.

Outcomes

• A platform where pages are published by composing components visually, without surrendering the structure that makes them maintainable.
• One typed contract drives the dashboard, the template engine, and the frontend consumer, so what is edited is what ships.
• Custom components added through a typed data model, keeping the builder open to extension without forking the editor.
• A frontend template consumer that calls the API with an API key and renders pages from the structured data the editor produces.