webCOMAND

Contentful, Contentstack, GraphCMS, Kentico Cloud, webCOMAND

Headless CMS Comparison - Model

Model

All reviewed systems offer a slick user interface to define content types.  Enter a name, add fields from a palette of types and drag-and-drop to reorder fields.  Field-specific options restrict field values, define custom validations and enable language localization.

All services provide the following field options, unless otherwise specified further below.

  • Data Types - Boolean, Number, Decimal, Date, Time, Date & Time, Text Line, Text Box, Rich Text, Markdown, File, Image, Color, URL Slug, Location, Select, Multiple.
  • Relationships - Reference One, Reference Many, Embed One, Embed Many.
  • Validations - Required, unique, text length, pattern match, specific values.
Model Contentful Contentstack GraphCMS Kentico Cloud webCOMAND
UI/UX (Ease of Use) ★★★★★ ★★★★★ ★★★★ ★★★★ ★★★☆☆
Data Types ★★★★ ★★★★★ ★★★★ ★★★☆☆ ★★★★★
Relationships ★★★★ ★★★★ ★★★☆☆ ★★★☆☆ ★★★★
Content Assumptions ★★★★★ ★★★★ ★★★★★ ★★★★ ★★★★★
Inheritance
Language Localization ★★★★★ ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★☆☆
Custom Variants
Validation ★★★★ ★★★★ ★★★★ ★★★★ ★★★★★
Limits ★★★★ ★★★★ ★★★☆☆ ★★★☆☆ ★★★★★
Total Score ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★★

Contentful  - Model

Contentful has the most straight-forward content modeling interface.  Add a content type, add fields, reorder and edit fields as needed.  They have done an excellent job of making this process as simple as possible while providing the options needed in real-world models.

contentful-types.png contentful-fields.png
  • UI/UX (Ease of Use) - Adding content types, fields and field options is straight-forward.
  • Data Types - Supports all common data types, except Files and Images are managed as Assets.
  • Relationships - Reference fields can be limited to any number of content types.  No embed relationships for fields, but rich text fields offer a free-form alternative.
  • Content Assumptions - No built-in fields pollute your content type fields, offering complete control of fields.
  • Inheritance - Inheritance is not available.  If two content types share the same base fields, duplicate field sets must be managed redundantly.
  • Language Localization - Localization can be easily enabled per field.
  • Custom Variants - Custom variants beyond Localization are not supported.
  • Validations - Best balance of options and ease of use.  Provides all common options, including regular expressions for more complex pattern matching with presets for common ones like E-Mail, URL, etc.
  • Limits - 50 field max per content type.  50,000 characters in a long text field.  API Content Type IDs (ie. “article”) can not be changed after creation.  See more limits.

Contentstack - Model

Content types are differentiated based on what they will represent:

  • web page (will have a unique URL) or content block (no URL)?
  • single (ie. home page or header) or multiple (ie. blog posts or contacts)?

Contentstack assumes you want a text Title for all content types and a URL for web pages, which gives you a jump start once the options above are set.  This illustrates how it is geared specifically to web content with titles, which is nice if that is the only type of content you plan to manage, but might be a mismatch if you want to manage other types of data and content.

contentstack-types.png contentstack-fields.png
  • UI/UX (Ease of Use) - Adding content types, fields and field options is straight-forward.
  • Data Types - Supports all common data types, except Decimal and Location not available.  Images and Files are managed as Assets.
  • Relationships - Reference fields limited to one type.  Embed fields allow multiple types.
  • Content Assumptions - All content types must have a text Title, which might be a mismatch if you want to manage other types of data and content.
  • Inheritance - Inheritance is not available.  If two content types share the same base fields, duplicate field sets must be managed redundantly.
  • Language Localization - Localization is enabled "globally" for all content types and fields in a stack (content library).  A single master language can be used as a fallback for all non-localized content.  Each content entry can be localized into any number of languages.  Entries not localized will fallback to the "global" master language.  Each entire content entry is localized to a specific language or not.
  • Custom Variants - Custom variants beyond Localization are not supported.
  • Validations - Built-in (required, unique, number of characters, file types, max file size, date range) and custom (regex) field-level validations, including custom error messages.  No type-level (cross-field) validations.
  • Limits - 100 field max per content type.

GraphCMS - Model

Very straightforward.  Models (aka content types) listed on the left with the selected content type’s fields on the right.  A field palette slides out from the far right to add new fields.  No content type search for large sets, but easy to scroll through the alphabetic listing and use your browser find.

graphcms-fields.png
  • UI/UX (Ease of Use) - Adding content types, fields and field options is straight-forward.
  • Data Types - Supports all common data types, except Rich Text (HTML), Color and Location field types are not available.
  • Relationships - No embed fields.  Reference fields are limited to one type and must have a reciprocal field.  Reciprocal fields can be hidden from the UI if undesirable.
  • Content Assumptions - No built-in fields pollute your content type fields, offering complete control of fields.
  • Inheritance - Inheritance is not available.  If two content types share the same base fields, duplicate field sets must be managed redundantly.
  • Language Localization - Localization can be easily enabled per field.
  • Custom Variants - Custom variants beyond Localization are not supported.
  • Validations - Limited to just required and unique.  Missing text length, pattern matching, etc.
  • Limits - Unknown.

Kentico Cloud - Model

Kentico Cloud has more freeform/ambiguous content fields and relationships.  For example, there is no distinction between a text line and a text box, so there is no way to limit a text field to a single line of text.  Rich Text fields enable embed relationships, which is a unique and powerful feature, but it also has no restrictions, so there is no way to limit a rich text field to just text or only certain embed content types.  There is a nice simplicity to this, but it allows editors to create incompatible or inappropriate content.  On the other hand, it does offer “Linked items” fields for restricted reference relationships (by number and types), which is similar to the other services.  Content Type restrictions are more of a recommendation than a true restriction, so again nothing will prevent content authors from linking to content types they shouldn’t.

kentico-cloud-types.png kentico-cloud-fields.png
  • UI/UX (Ease of Use) - Adding content types, fields and field options is straight-forward.
  • Data Types - Supports all common data types, except there is no distinction between Text Line/Text Box, Number/Decimal and Date/Time/Date & Time.  Markdown, Color, Location are not currently available.  Image/Files are managed as Assets.  Times only store hours and minutes, but no seconds, which may be important in some cases.
  • Relationships - Embed relationships (“content items” in Kentico Cloud) only available through Rich Text fields.
  • Content Assumptions - All content types must have a text Title, which might be a mismatch if you want to manage other types of data and content.  The built-in Title is also shared across locales, so it can not be translated.  If you have a Title that is to be translated, you will need to create a custom Title field.
  • Inheritance - Inheritance is not available.  If two content types share the same base fields, duplicate field sets must be managed redundantly.
  • Language Localization - Localization is enabled "globally" for all content types and fields in a project (content library).  A "global" chain of language fallbacks can be defined to find the best matching language for all non-localized content.  Each content entry can be localized into any number of languages.  Entries not localized will fallback to the appropriate language.  Each entire content entry is localized to a specific language or not (no per field fallback).
  • Custom Variants - Custom variants beyond Localization are not supported.
  • Validations - Built-in per-field validations (required, maximum characters/words)
  • Limits - Unknown

webCOMAND - Model

Content types can inherit fields from other content types, so when an inherited content type’s fields change, all content types that inherit it also change.  Scripted validation can modify values (ie. trim white space and process images), consider multiple field values, file types and more.  Content titles, descriptions and indexed keywords can all be customized.  It is the only service that offers custom dimensions, beyond just language localization, which can be used to manage variants specific to market segments, formats, channels, etc.  Overall, a more flexible and powerful system, but at the cost of simplicity and ease of use for developers.

webcomand-fields.png
  • UI/UX (Ease of Use) - Adding content types, fields and most field options is straight-forward.  However, adding enumerations, validations and some other field options is less straight-forward.
  • Data Types - Supports all common data types, except Markdown is not currently available.
  • Relationships - Relationships are limited to one type or any types that inherit it, with no option to limit to a single type (if it is inherited) or arbitrary set of types.
  • Content Assumptions - No built-in fields pollute your content type fields, offering complete control of fields.
  • Inheritance - A content type can inherit fields from another content type so that if an inherited content type’s fields change, all content types that inherit it also change, including support for full hierarchies.
  • Language Localization - Localization is enabled per content type.  A chain of language fallbacks can be defined per-entry to specify the best matching language for all non-localized versions of the entry.  Each content entry can be localized into any number of languages.  Each entire content entry is localized to a specific language or not (no per field fallback).
  • Custom Variants - Any number of custom variants are supported.  Variants can be queried and retrieved based on multiple variant preferences with optional fallbacks.  Each content item can also define their own default variant and preferred fallback order to use when preferred variants are not available.
  • Validations - Both client-side (regex) and server-side (regex and scripts) validations are possible.  This means that just about any imaginable validation is possible, including on files and images.  The downside is that they are not as quick or easy to set up as with other services, even something as simple as “required”.
  • Limits - Long text and file fields are limited to 64MB each (can be increased in Enterprise accounts).  No content type or field maximums.