Headless CMS with Event System Diagram

This blog post presents a diagram of a possible headless CMS architecture with search that uses a brokerage architecture and an event system for webhooks and API calls.

For background information, see:

• Centralizing [Headless] [CMS] Data Access – Deliverystack.net
• Web Service Brokerage Architecture [for Headless CMS] – Deliverystack.net
• Integrating Event Systems with Headless CMS – Deliverystack.net

In this diagram, the dotted lines represent optional connections. Except in cases where cost and performance considerations outweigh endpoint ownership considerations, applications should only call brokered APIs, not APIs hosted by vendors. Webhooks should invoke brokered APIs that publish events in the event system. The service broker intercepts all webhooks and API calls, publishing events to the event system as appropriate.

The build process may invoke services to retrieve configuration, text content, media before or after server-side manipulation, and anything else from the CMS to embed statically in the content delivery solution. The build process could retrieve media directly from the CMS or the service broker could provide media URLs, for example by translating CMS media URLs to custom media URLs.

The content delivery solution may use the service broker to retrieve content from the CMS. The content delivery solution could subscribe to events, for example to clear caches, though caches are likely better managed by process orchestration.

Visitors access the content delivery solution and may retrieve content from the service broker. Though it would violate the objective of customers to own their own endpoints, in addition to or instead of using the service broker, visitor devices could access the search engine and the vendor’s CDNs for content and media services directly, potentially using access information provided by the service broker. Preferably, the solution would broker search queries, content delivery services, and media requests.

The CMS user interface accesses the CMS. Customizations in the CMS user interface could invoke service brokerage APIs and subscribe to events.

CMS webhooks access the service broker, which typically publishes the event. In addition to other functions such as periodic processes, process orchestration subscribes to events and uses them to interface with systems that are not aware of the event system. For example, a feature in process orchestration could subscribe to publishing events created from publishing webhooks and pass the published data through the service brokerage to a search engine for indexing.

Systems that customers control can subscribe to events rather than requiring process orchestration to convert events to webhook calls.

If you have any feedback regarding this architecture and diagram, please comment on this blog post.