Evaluating [SaaS] [Headless] [CMS] Data Modeling Capabilities

This blog post contains information about evaluating data modeling capabilities in SaaS headless content management systems, specifically features available in content types that define different types of structures for data storage. Data modeling is one of the critical features of and differentiating factors between headless content management systems. If you have additional perspectives about modeling capabilities in SaaS headless content management systems, please comment on this blog post.

Default Field Types

• Consider the number and variety of field types. Date and Date/Time are not significantly different. Markdown and markup are significantly different.
• Consider whether each field type can store multiple values. For example, CMS users working with long pages may want to implement sequential HTML blocks rather than a single block.
• Consider native data storage formats and where transformations may occur. For example, if a CMS vendor represents markup as JSON, consider responsibility for converting that JSON to markup and caching that data as needed, as well as potential required knowledge and code against that JSON structure for customization (alternatively, customize the rendered markup).
• Consider how the various field types store references to media assets and other entries. What happens on deletion of the target of such a reference? If the reference is a URL, what happens if URLs changes?
• Evaluate the parameters available for configuring each field type, such as populating drop-down lists, WYSIWYG and markdown editor features, validation, and otherwise.

Custom Field Types and other User Interfaces

• Review the custom field types available from the vendor by default and whether the source code and documentation provided will be sufficient to help you implement any custom field types that you may need.
• Evaluate the simplicity and level of vendor-specific knowledge and code required to implement custom field types and other custom user interfaces in the CMS.
• Ensure that you can hose custom user interfaces in the CMS or on your own infrastructure according to your needs and preferences.
• Ensure that any suggested or required UI frameworks are acceptable for your solutions.

Groups of Fields

• Ensure that you can create groups of fields to visually and structurally separate related values from other data in the entry.
• Consider whether you may require and whether the CMS supports repeating groups of fields, for example to implement a FAQ.

Reusable Structure Definitions

• Evaluate whether that multiple content types can reuse groups of fields and other structure definitions, reducing development effort while increasing consistency and hence CMS usability. For example, the same types of metadata may appear in all web pages, meaning that all web page content types should re-use a single metadata field structure.

Complex Data Structures

• Evaluate how the CMS manages complex structures.
• Evaluate how the CMS represents and manages references between entries.
• Evaluate whether the CMS allows nesting of complex structures within entries (compare to Contentstack modular blocks).
• Some CMS allow editing and other management of referenced or grouped entries as a unit, where managing large numbers of entries separately may be cumbersome otherwise.

JSON Formats

• Evaluate the raw JSON formats produced by the CMS. Confirm that their structures will work for your solution. How the CMS represents schema definitions is generally less important than how the solution represent data, as most solutions work with schemas using conventions rather than interrogating their structure. To support migrating from one CMS to another, avoid JSON formats that appear to be vendor-specific rather than specific only to your content types.