Content Modeling with the Contentstack SaaS Headless CMS

A solid, long-term information architecture, specifically in the form of stacks, content types, and collections of entries, optimizes implementation and maintenance. This blog post contains information about content modeling with the Contentstack SaaS headless content management system. If you have additional suggestions about related topics, please comment on this blog post.

I am trying to cut down on links, so if you are interested in further detail about these concepts, refer to the Contentstack documentation and maybe scroll through the topics at deliverystack.net periodically.

For context, here are some oversimplified definitions relevant to content modeling with Contentstack.

• Organization: Container for resources such as users, groups/roles, and stacks.
• Stack: Container for resources such as content type definitions, entries, metadata about binary assets, configuration including webhooks and user interface extensions, and other data.
• Content Type: Defines the fields that make up a type of entry.
• Entry: A unit of data consisting of system properties and some number of values for the fields defined in its content type.
• Asset: An entry that contains metadata about a binary resource such as an image.
• Field: An individual unit of data with properties such as data type that control its appearance, storage format, and functionality.
• Group: A group of fields that are visually distinct and logically cohesive.
• Global: A definition of a group that multiple content types can share.
• Modular Field: A field that contain various types of blocks, which are similar to groups in that they have a consistent structure, but different types of blocks can appear within a single field value.

With Contentstack, data modeling should be the process of analyzing an information architecture to determine the following requirements.

• Culture-specific considerations including the impact of locales on URLs.
• The required stacks.
• The required content types.
• What entries will exist.
• How entries will reference assets and other entries and other relationships between entries, such as explicit hierarchies or implicit hierarchies based on URLs.
• How to map incoming URLs to entries.
• The fields, groups, and blocks required for each content type.
• Field types and properties.
• Which structures are global.
• Which complex data structures to implement as modular fields and which to implement as separate content types and referenced entries.
• Any need for custom field types, such as to integrate with external systems, typically by referencing external URLs or other identifiers.
• Search indexes and their fields (optional).

While headless CMS supports omnichannel content delivery, most solutions begin with a focus on websites. Websites generally consist of web pages assembled from components. Entries in the headless CMS contain data for pages and components.

Irrespective of the platform, perform significant analysis before implementation. Any code that uses the CMS will depend on the structure of the content types. It may be possible and appropriate to define content types based on an existing data model. It is critical to focus on requirements for their structure rather than excessive specifics such as HTML field validation. With a thorough analysis, implementation of both content types and content delivery should be straightforward. Beyond changing field properties and adding fields, changing content type definitions after developing code presents challenges similar to changing relational database tables after writing SQL.

For common page and component data structures, data modeling should be relatively straightforward. With Contentstack, a significant concern is when to use modular fields rather than separate entries. Again, modular blocks allow CMS users to create some number of various types of data blocks that appear as a single field value.

In general, I lean towards modular blocks whenever possible for the following reasons, which combine into one of the major reasons that I work with Contentstack. I also seem to think that most modular blocks should be global.

• Modular blocks optimize CMS usability for working with large and complex data structures.
• Modular blocks let CMS users manage large and complex data structures as a single unit rather than separate entries, which can have advantages for translation and other workflow processes.
• Using modular blocks does not prevent data re-use, so there is no need to implement separate content types and entries for every type of data fragment.
• It is faster and easier to implement new features, and I expect to deploy them, with modular blocks rather than separate content types.
• Modular blocks can reduce HTTP calls to the CMS, which can improve performance and reduce costs.

Of course, do not take modular blocks too far. The entire website should not be a single entry in the CMS. Typically, every page should be an entry, although some entries may not have URLs except when their data appears in search results. Use modular blocks for fluid page design. Where modular blocks are not appropriate, consider carefully how entries will reference other entries.

All web pages will always have some data structures in common including at least the following components.

• A URL that consists of several values including protocol, host, port, path, and query string.
• Title values such as a full title used as the tab, bookmark, and search results title and a separate short title used for navigation links.
• Metadata including the HTML <title>, <meta> keywords and description, OpenGraph values, data for sitemap.xml, search, and other elements.

In Contentstack, you can use a global group to model these values as a collection of fields. Then, include this global group in each content type that represents a page.

I think that every solution should begin with at least one search index that allows content delivery systems to query and potentially retrieve data without accessing the CMS. Consider how search will expose data shared to multiple pages. In general, each data element should have one and only one URL.