Integrating Event Systems with Headless CMS

This blog post provides some perspective on implementing event systems with headless CMS. While the content may apply to any system, I am familiar with the Contentstack SaaS headless CMS and barely familiar with Apache Kafka with some memory of my use of TIBCO in the late 1990s.

For an event system or anything else, there are only three integration points in a headless CMS.

• APIs: Systems that subscribe to CMS events could also invoke CMS APIs.
• CMS UI: Logic in CMS UI extensions could employ event systems.
• Webhooks: CMS webhooks could place payloads on the event system.

I cannot see cases where an event system would invoke CMS APIs. For organizations with sufficient resources, I can envision monitoring dashboards, long-running UI processes, and other CMS UI extensions that use event data. Using an event bus to manage data from CMS webhooks could allow some possibilities.

For example, publication is the most important signal from the content management environment to the content delivery environment. In addition to clearing caches, publication can trigger updating and rebuilding of search indexes, all of which should not affect content delivery. Contentstack invokes a webhook each time it publishes an entry, which would lead to ineffective caching during publishing operations and inefficient indexing of individual entries. Additionally, since entries can reference other entries and references may be circular, references may appear before referenced data, resulting in nondeterministic outcomes.

While there are other techniques to address these concerns, such as aggregating data for indexing and delaying cache clearing, one solution is to intercept publishing webhooks and place the data in an event system. Subscribing systems could periodically poll for completed publishing operations, updating and rebuilding search indexes and managing caches more reliably and efficiently. Remember to consider all kinds of publishing, from small operations up to major releases including content type changes. For more information about rebuilding and updating indexes with headless CMS, see What and How to Index for Search with Headless CMS – Deliverystack.net.

Using content management APIs, an event system could apply in process automation, such provisioning new systems or build and release management. For example, an orchestration engine could use the event system to manage the creation of new projects by provisioning a content management repository, creating DNS entries and search indexes, and so forth, potentially including development, test, and production environments, search tokens, and otherwise. An event system could be useful in monitoring long-running provisioning processes through a CMS UI.

Because you cannot extend the CMS with server-side logic, other than within a CMS UI extension, you cannot implement any CMS functionality that subscribes to events. You can implement subscribers that invoke CMS APIs.

Considering performance, complexity, failure points, and other factors, I speculate that webhook and API service brokerage as described in Web Service Brokerage Architecture [for Headless CMS] – Deliverystack.net is most appropriate for logic that publishes events, but subscribers may connect directly to the event system. An event system centralizes data access as described in Centralizing [Headless] [CMS] Data Access – Deliverystack.net, but accessing an event system directly omits a layer for abstraction and instrumentation while creating vendor and vendor knowledge dependence.

If you have any suggestions for using event systems with headless CMS, please comment on this blog post.