CMS Less for High Availability, Performance, and Concurrency

The events open to the public, in general, have thousands of concurrent users and if it needs some content/component administrator (CMS) it’s common to think in an infrastructure with autoscaling, front cache (CDN), data saving on Memcache or Redis, and WAF. Among other tools.

E.g. Infrastructure

E.g. Monolithic Arch CMS

Why CMS Less?

This concept can be used when it’s necessary to build a static website that requires manageable components without a direct dependency on a Content Management System (CMS) using JSON/YAML files as data providers and stored in a CDN. The main advantage of using CMS Less is obvious when the CMS is offline because the static website won’t be affected and will continue working normally. The main idea of this is to use the CDN all the time.

Isn’t necessary to think about creating a complex infrastructure for the CMS, because this only will be used to create/update the data structures and assets in the CDN.

In some form, the base idea is to have high cohesion and low coupling but across all application behavior. A totally decoupled CMS for editorial activities and a progressive Web App generator to support all concurrency.

Why isn’t used Headless here?

The intention is also to reduce the infrastructure operation cost when the website has a lot of concurrent users, using a Headless strategy with an API exposed by a monolithic CMS is probably an expensive option because it needs an infrastructure with load balancing to process all requests sent from a static website.

How CMS Less works?

The Content Management System sends all components of content data using JSON/YAML files and their assets (images, documents, or videos) to the CDN created using Amazon Cloudfront, Azure CDN, or any similar tool.

The static website can be developed using tools such as Vue.js, React, Gatsby, or Angular. Among other tools. This tool has the responsibility of:

• Consume the JSON/YAML files and assets pushed by the CMS into the CDN.
• Split the structure of the static website using components to set the data/files provided from the CDN.

Items to have in mind to this works perfectly:

• The communication between data providers and a static website is CDN to CDN.
• Component mirror, each administrable item should have a frontend mirror.

Pros and Cons

Pros

• High Performance.
• High Availability.
• Low infrastructure cost.
• Use any tool to develop the static website.
• Support to simultaneously user concurrency.
• Doesn’t exist a direct connection with the CMS.
• Development of backend and frontend in parallel.

Cons

• There is not a content preview before publishing (this does not mean that it is not possible to develop, only needs more implementation time).
• So far, website personalization and segmentation are not implemented in this approach.
• It is necessary to have good synchronization between frontend and backend developers to avoid bottleneck or unbalanced tasks among the dev team.

Future Work

The website Personalization and segmentation using CMS Less is the natural campaign amplification to involve our potential audience. This proposed solution is oriented to use components that can work with personalization and segmentation.

How to implement it, is a clear opportunity to add more capabilities to CMS Less approach.