DEV Community

Cover image for Technical Architecture of EZ EDGE CMS
Evgenii Zinner
Evgenii Zinner

Posted on

Technical Architecture of EZ EDGE CMS

I developed EZ EDGE CMS with a specific goal: to create a content management system that runs entirely on Cloudflare Workers without the bloat of traditional frameworks. By moving styling, image processing, and SEO logic to the edge, I’ve eliminated the need for origin servers and complex build pipelines.

Here is the technical breakdown of the engine and the trade-offs I made to keep it fast.

1. Zero-CSS Middleware (with Theme Constraints)

EZ EDGE CMS has no static CSS files. I integrated a Just-In-Time (JIT) UnoCSS middleware that runs at the edge. When a request is made:

  1. The middleware scans the HTML content.
  2. It generates the minimal utility classes required for that specific page.
  3. It injects the CSS directly into the . The Restriction: To maintain this performance, you cannot upload custom CSS files. You are limited to built-in themes where you can only customize colors and fonts. This ensures the JIT engine stays lightweight and prevents slowing down the edge isolate.

2. Edge-Native Image Processing

Instead of relying on external S3 buckets or heavy image transformation services, I handle assets directly within the Worker:

  • WebP Conversion & Resizing: When you upload an image, the CMS automatically resizes it and converts it to WebP format. This ensures maximum compression and faster loading times for end-users.
  • KV Binary Storage: Images are stored as Uint8Array binaries in Cloudflare KV. They are served from the same edge location as your content.
  • Garbage Collection: When you save a page, I've implemented logic that identifies "orphaned" images (assets no longer used in your content) and deletes them from KV to keep your storage costs at zero or near-zero.

3. Automated SEO & JSON-LD Graphs

I dont like to manually manage metadata, so I automated the SEO layer using Schema.org JSON-LD graphs.

  • Automated SEO Layer: Replaced manual metadata management with a dynamic system built on Schema.org JSON-LD graphs to provide search engines with a high-accuracy site map.
  • Persona Integration: Automatically injects identity data (Organization/Owner) directly into the page structure.
  • Dynamic Breadcrumbs: Generates a real-time BreadcrumbList hierarchy that maps the page’s exact position.
  • Automated Asset Delivery: Serves optimized Open Graph (OG) images and tailored meta tags without manual updates.
  • Structured Metadata: Pulls standard SEO values from the CMS editor.

4. Script Injection for Interactivity

Since the themes are constrained, I added the ability to inject Global and Page-Related Scripts.

  • Global Scripts: Useful for adding analytics (like Google Analytics or Plausible) or sitewide chat widgets.
  • Page Scripts: Allows you to add specific functionality to a single page without bloating the rest of the site.

5. Block-Based Editor

To ensure the edge engine receives clean, predictable data, I integrated Editor.js. Unlike traditional WYSIWYG editors we store and parse a clean JSON structure.

  • Structured Data: The CMS stores content as JSON blocks, which are then parsed at the edge into semantic HTML.
  • Clean Output: This ensures that the JIT CSS engine (mentioned below) only scans valid, structured content, reducing processing overhead.
  • Extensibility: I’ve plan to customize editor to handle specific blocks that sync perfectly with the edge-native theme.

6. Current Technical Restrictions

Being honest about the limitations is part of the "Edge-Native" philosophy. If you use EZ EDGE CMS, you need to be aware of these:

  • Design Limits: You cannot build a "from-scratch" custom layout. You must work within the parameters of my optimized built-in themes (Colors/Fonts only).
  • 25MB Value Limit: Cloudflare KV has a hard limit of 25MB per entry. This applies to individual pages and images.
  • Propagation Delay: While the updateQueue prevents write errors, it can still take up to 60 seconds for a new post to appear in every single Cloudflare data center globally due to KV's native consistency model.
  • Limitation for distributed teams: Currently recommended for solo work; without Durable Objects for atomic locking, simultaneous editing by multiple users is not possible to avoid data loss due to "last write wins" conflicts.

It is in a POC stage now, I need some time to work with it to shape a finalized vision and fix bugs, but i welcome everyone who willing to try or contribute
See it in action: First website made on EZ EDGE CMS
Explore the Code: Source code
Try it yourself: Deploy to Cloudflare Workers

Top comments (0)