Centralizing [Headless] [CMS] Data Access

This blog post presents potential advantages of centralizing access to data in Content Management System (CMS).

While often used to manage the content of websites, content management systems can manage any type of data for any delivery channel such as print, mobile apps, kiosks, and otherwise.

Content management systems can provide access to data in at least three major ways:

• Through platform-native APIs that use databases and other direct connections
• Through HTTPS services that expose APIs
• Through data exports to various formats and repositories

Some content management systems provide platform-native content delivery engines such as for PHP or ASP.NET. Headless, or service-oriented content management systems, implement all CMS interactions as HTTPS services, and provide SDKs for specific technologies to wrap those services as platform-native APIs.

Whether platform-native or service-oriented, all CMS products provide APIs that accept an identifier, such as a URL or unique ID, or a query that specifies criteria, and return matching records, as this is the most common use case in content management.

There are three stages at which a solution can access data from the CMS:

• Statically during the build process, such as to embed managed content statically in the deployed solution
• Dynamically from the server, such as when generating HTML for a browser
• Dynamically from client applications, such as when rendering in a browser or mobile app

Whether services or platform-native APIs, without some effort to centralize access to CMS APIs, vendor-specific code may appear in numerous solutions. In this case, all developers responsible for accessing the CMS must be familiar with proprietary APIs and data formats rather than only common web technologies such as JavaScript, HTML, and CSS.

Rather than scattering vendor-specific code throughout all solutions, engineers can implement architecture that centralize access to the CMS. In such architectures, content delivery solutions depend on a CMS access layer that exposes a generic data retrieval API that returns JSON or objects hydrated from JSON. Optimally, this layer is implemented as a service wrapped by platform-native API. In .NET solutions, a single centralization project would depend on the CMS vendor SDK and expose an API to access data; all other projects would have no knowledge of the CMS, only the centralization project.

Centralizing access to data from the CMS has the following advantages:

• Some solutions can cache data to improve performance.
• Centralization simplifies changing the implementation. For example, data that comes from the CMS today may come from a search index tomorrow, or the organization may migrate from one CMS to another.
• Centralization provides a consistent programming interface for developers, who need know only that data access layer rather than CMS implantation details.
• Organizations can use the centralization layer to merge and massage data from multiple systems.
• Centralizing access allows testing of alternate implementations such as different caching technologies, different techniques for preloading caches, and performance comparisons between using content delivery APIs, GraphQL, and search indexes.
• Centralized access allow control over data access without requiring distribution of security tokens.
• Centralization can reduce use of CMS vendor HTTPS services, which can lower costs.
• Centralization can insulate downstream systems from changes in data formats and other implementation details.
• Centralization can map data to data types, populate objects of specific types when retrieving data, prerender HTML, and provide other advantages.

Centralizing access to the CMS has some disadvantages:

• The central API must abstract and wrap all vendor-specific APIs required by the solution.
• To support migration from one CMS to another, the API should only implement features supported by all potential CMS vendors.
• If it is a service APIs, then the organization must host the central API, which significantly reduces the value of a CMS vendor’s content delivery services and its CDN.
• Some CMS product architectures do not lend themselves well to centralization.

In a way, I see some of these as advantages, as I do not want my solutions to use CMS APIs (see The (Best) [CMS] API Has No Methods – Deliverystack.net). In fact, I think that most solutions can benefit from querying and retrieving data directly from a search engine rather than the CMS.

While using a centralized API for CMS data access seems to require effort to reduce functionality and potentially performance, consider the difference in effort between changing the code in all your pages that access the CMS and the effort in changing a single data access layer. Centralization adds even more value where application servers cache data from the CMS or use search indexes.

After writing this, it seems that conceptually, headless does not seem to have much impact on the advantages or disadvantages of centralization, but may simplify implementation relative to solutions that couple content delivery with content management more tightly.

If you have perspective on whether, how, and why to centralize data access, especially in headless content management systems, please comment on this blog post.