Web Service Brokerage Architecture [for Headless CMS]

This blog post suggests that organizations, especially headless CMS customers, employ service brokerage architectures for service-oriented applications to control the endpoints used by their applications. This post focuses primarily on HTTPS endpoints that serve JSON for content delivery in headless CMS implementations, but many of these considerations apply to other systems as well as webhooks and message buses.

I believe that customers should centralize all data access and own all service endpoints (Centralizing [Headless] [CMS] Data Access – Deliverystack.net). In the context of HTTPS services that exchange JSON, a data access centralization layer can function as a service broker, securing, modifying, routing, forwarding, and/or otherwise managing all service calls from internal applications as well as external parties. Such a service broker can insulate applications from changes in other applications, such as migrations between vendors that affect API endpoints and JSON formats.

In most cases, owning an endpoint may be as simple as wrapping an endpoint provided by a SaaS vendor. For example, a Jamstack application may consume data from a SaaS headless content management system. Rather than having the client access the CMS vendor’s API endpoint directly, the CMS customer can host an equivalent service that in most cases simply forwards the request from the client to the CMS. This layer can manage CMS access security, modify requests and responses, cache data, and provide additional value with simple serverless function implementations.

The same holds true for media managed in the CMS. Customers may prefer to use their own CDNs to host media delivery, for example to gate, pre-render image manipulation during the build process, or otherwise control media URLs.

The service broker would broker services for all applications, not just headless CMS. For example, most web solutions integrate with hosted search solutions. In such cases, I think that I would allow clients to pass vendor-specific query formats rather than implementing an abstraction layer over the search vendor’s API.

For both text and binary content, it is important to consider the additional hosting costs, network and other performance effect, and other impact of adding a layer over the CMS vendor’s CDN, the reliability and other risks and advantages of adding an additional layer, as well as caching and cache clearing complexities, and determine strategies to address those concerns. In some cases, caching data from the CMS can improve performance and reduce costs, specifically to the CMS vendors content CDN.

In a typical headless CMS implementation, the content delivery tier delivers content access tokens to clients. In a service brokerage architecture, the service broker can manage access tokens without exposing them to clients.

A service broker can merge, manipulate, secure, and otherwise manage data from one or more CMS repositories, search indexes, and other sources before its delivery to clients.

A service broker can translate vendor-specific JSON formats to customer-specific formats, facilitating development and insulating systems from changes in other systems.

If you own your service endpoints, then you can instrument those service endpoints, for example logging, tracing, debugging, performance monitoring, error control, and otherwise.

Using a service brokerage architecture allows centralized change management, insulating customer solutions from vendor specifics and changes to service-oriented applications.

Implementing a service brokerage architecture implies documenting all services exposed by all applications rather than implementing code that can invoke any service.

If you have perspectives on HTTPS service broker architectures, especially for headless content management systems, please comment on this blog post.