Five Reasons Why You Should Use a Git-based CMS (Part 3 of 5)

Most CMS technologies are what we would call a “coupled CMS.”  The content authoring and content delivery environments are usually part of the same stack. The act of “going live” with new content or a feature is essentially based on the act of marking a true/false in a database field. There are a lot of problems with coupled CMS platforms around security, performance, scalability, and flexibility (you can learn more here.)

For these reasons and many others, Crafter CMS is built as a decoupled CMS. With a decoupled CMS you author content in one system and publish to another separate system. For platforms like Crafter CMS that are decoupled, when correctly implemented, the architecture provides great solutions for the issues mentioned above. That said, nothing is without its challenges. Decoupled systems, by their nature, are typically very scalable and can have many instances all over the world. Security, scalability, and distribution are no longer issues that only concern the Internet’s biggest players like Google and Amazon.  Security and distribution impact customer experience, safety and help reduce operating costs.  Every brand-conscious and customer-forward organization in the world is focused on these tactical issues.

Once you have a decoupled, distributable deployment model, the challenge becomes making certain that the content on the servers all over the world is the same — everywhere. Every decoupled solution has an approach for this. Some better than others. That said, few if any of the approaches offered out of the box by today’s traditional CMS platforms “mathematically” ensure every remote instance is 100% up to date and in sync with every other instance. If there are bugs in the deployment code or there is trouble in the environment you may get out of sync.

In our previous posts, we looked at Crafter CMS and its Git-based versioning (part 1) and distributed repository (part 2).  In this post, we’ll take a deeper dive into how Crafter CMS leverages Git mechanics to provide a better, more consistent distributed publishing mechanism.

Reason #3: Distributed, scalable, consistent publishing

Crafter CMS uses Git mechanics to publish content to its decoupled delivery space. When Git reports that its repository is set at a specific version that means that every file is guaranteed to be present and in the proper state for that version, it is. Fact. It’s provable.

The reason it’s provable is due to the fact that the Git mechanics that underlie Crafter CMS’ content repository are based on Git’s purely functional data structures. “The main difference between an arbitrary data structure and a purely functional one is that the latter is (strongly) immutable” (Wikipedia).  What this means is that as commits happen within the repository an entirely new immutable data structure is created containing the changes for the commit. No action is taking on the previous data structure(s.)  Nothing you ever change can be lost or corrupted by an operation once the change has been committed.  Moreover, in Git, the ID for the commit is essentially a SHA1-hash of metadata and the content in the directory tree. By definition, if a single bit changes anywhere in the tree a new SHA1-hash must be generated.

 

While this explanation is an oversimplification of Git’s algorithm, it is essentially the model of how it works. The point is that two repositories on two different machines with the same commit ID are mathematically guaranteed to be the same. That’s an extremely useful mechanism for versioning but it also is a very large helping hand in publishing. Crafter CMS publishes (replicates) content based on Git commits. If you want to know if an endpoint on the other side of the world is the same as what you expect, you only have to compare the commit ID(s).

In today’s elastically scalable, globally distributed world you can have any number of servers.  You need a means to make sure they are all in sync. As you can see above, Git’s internal mechanics give us just that.  Crafter CMS is the first decoupled CMS with the capacity to scale geographically across an elastic cloud and at the same time make 100% certain that remote instances are consistently running the same version of content and code.

CONCLUSION

Decoupled CMS platforms provide push-based publishing, offer greater architectural flexibility and are much easier to scale elastically and distribute globally.  Along with this increased power and flexibility comes a need to ensure that all remote endpoints are in sync with one another and are up to date.  While this problem is solvable, few of today’s decoupled CMS platforms provide a solution for this that is 100% guaranteed and mathematically verifiable.  Crafter CMS and its Git-based repository leverage Git mechanics for publishing and replication to remote nodes.  Calculating changesets and verifying that an endpoint is in a particular state is based on the proven algorithms and data structures that back Git, the world’s most powerful and popular distributed source repository.
Stay tuned for our next blog entry to learn another major reason why you should use a Git-based CMS!

Five Reasons Why You Should Use a Git-based CMS (Part 1 of 5)

Crafter CMS is a revolutionary open source digital experience platform based on Git. Crafter CMS solves problems from scalability and performance to ease of innovation that has existed in the CMS space for more than 20 years. What makes Crafter CMS so unique is its technical approach and underlying architecture. From its repository layer to its content delivery technology, Crafter CMS is designed to handle today’s most difficult content management challenges associated with creating and managing omnichannel digital experiences.

While there are many architectural advantages of Crafter CMS, in this series we will focus your attention on Crafter’s underlying repository technology: Git. Crafter CMS is the first and only enterprise-class CMS based on Git. We’ve based our CMS on Git for many reasons, and throughout this series, we’ll explore five of the most important.

Reason #1: Event-based multi-object versioning

Traditional CMS platforms like Drupal, WordPress, Adobe Experience Manager, Sitecore, and most others either have severely limited versioning or provide basic versioning capabilities that track single object graphs or maintain clunky data structures to track relationships.

Figure 1: Single file versioning model. Each object has its own version tree. How and whether relationships are tracked between objects differ from one system to the next.

Such simplistic approaches work for basic content management needs like blogs or boring websites but largely fall down in the face of managing today’s multi-object, multi-asset digital experiences. Today’s content models are component-based, and they have many relationships and dependencies. Further, there is often a relationship between the content and the code (CSS, Javascript, templates, etc.) that needs to be considered. Tracking the edits of any one specific object in isolation is simply not enough.

While simple object versioning does support basic editing, simple review, and basic reversion, these use cases are only the tip of the iceberg in a real-world environment. Scenarios like legal audits, company re-branding, and concurrent feature development drive the need for much more sophisticated CMS capabilities like a “time-machine” preview, multi-object reversion and content/codebase branching.

Instead of the single file versioning we see in the CMS space, what’s needed is a multi-object versioning approach like we see in the programming space. We require an approach that tracks “the entire state of the universe on each change.” With this level of version detail, a system can provide real previews at any point in time, make intelligent decisions about what must be reverted and support a host of branching and workflow needs.

Figure 2: Multi-object (“striped”) versioning model. Each event tracks the state of the entire repository at the time of the event.  

This type of solution already exists in the enterprise software development space. With software, one source file is often related to many others. Versions between objects matter. Modern Source Code Management (SCM) has evolved to support this need. Git is today’s most popular and widely used source code management system. It’s clear that the content and technical components of today’s digital experiences share many of the same needs that we see in the software development space. Rather than re-invent Git to achieve the same versioning capabilities in the context of content management, we’ve based Crafter CMS on Git’s versioning mechanics.

Because Crafter CMS is based on Git, every content change event is tracked with an event ID known as a “Commit ID.” Using this ID, it is possible to know the state of every content object in the system at the time of the event. For the sake of simplicity, we can say that we’ve created a version “stripe” across the entire repository at a given moment in time. The system does not make a copy of every object on every edit. That would be too slow and cost too much in terms of storage. Instead, this is done in a very efficient and effective manner by leveraging Git’s own proven versioning mechanics.

Moreover, because of the way Git stores and manages versions, traversals to any point in time are extremely fast. Performance is very important when it comes to the types of use cases we discussed earlier. Let’s take, for example, an auditing scenario: legal needs to see what the site looked like 46 days, 2 hours and 42 minutes ago. With most CMS platforms, this scenario is impossible to support. At best a systems group can attempt to restore a backup from that date and staff can be diverted to give the lawyers what they need. Even if your CMS claims to support this kind of review, the speed at which it can be provided is of key importance. If it’s too slow it won’t be practical. I’ve seen demos of CMS platforms that take minutes to render a previous version of a dynamic site. That’s too slow when you are doing a triage. It’s worse if you are traversing for editorial reasons. Crafter CMS simply doesn’t have this issue. Because of the way Git stores versions, traversal of versions n our Git-based CMS is extremely fast.

Finally, Crafter’s Git-based versioning approach itself hints at another important and related characteristic of Crafter CMS: content is managed in a document-oriented, file-based store. In short, content is stored as XML. Git is a file-based versioning system. Storing content as files are not only necessary, but the file-based approach has several major advantages. Because we’re dealing with files, content is easy to move among environments (Dev, QA, Prod, etc.) and migrate between systems. It’s much easier to integrate the content with other 3rd party systems, such as for language translation, e-commerce, and marketing automation. And because we store content in an XML format, it’s multi-byte character set friendly and totally extensible.

Conclusion

Most CMS’s lack the sophisticated versioning mechanics that are needed by today’s multi-disciplinary teams who are creating modern digital experiences. Today’s sophisticated digital experiences call for a much richer set of versioning mechanics similar to those we see in the software development space with Source Code Management Systems (SCMS.)  Git is today’s most powerful and popular SCMS. Because it’s based on Git, Crafter CMS is able to deliver the versioning needs for today’s most sophisticated needs and use cases.

Stay tuned for our next blog entry to learn more reasons why you should use a Git-based CMS!

Why Developers Should Care About CMS

As developers, we’ve got a strong handle on how to manage and deploy our code assets.  Yet every one of us, at some point in our application build has said, “What about this text? What about these images? Where do these belong?”  That’s pretty universal.  Nearly every single application today has content in it.  Be it a web app or a native app; it’s full of strings, images, icons, media and other classes of content.

This content doesn’t really belong in our code base — because it’s not code.  These non-code assets make us as developers pretty uneasy.  We know that at some point a business user is going to ask us to make a change to one of those strings and we’re going to spend hours of build and deploy cycles to handle a 30-second code change.  We know that at some point we’re going to need to translate that content.  We know at some point we’re going to replace this UI with another one.   We know all these things  — and we know leaving that content, even if it’s abstracted into a string table or a resource bundle is going to come back to haunt us; no matter the abstraction: it’s part of the build, developers need to update it.  Developers and Systems folks need to deploy it.  

Smart developers separate code from content.  They make sure that the content in the application is completely independent of the build and deploy cycle of the application itself.  Where appropriate they make sure non-technical business users and have access to the externalized content and can update it and publish changes at any time.

Consider the following scenario:  Your application is for an insurance company.  Along comes major regulation change.  Now your (and every other application) needs to change its language accordingly.  If the content was separate from the application the response time and cost to make changes is minimal.  It’s business as usual.  If the content is not separate you are looking at months of builds, testing and deployment that costs time, opportunity and a tremendous amount of money,

What we’re really talking about is application architecture.  Making the right decisions has significant impacts on our development teams and process and as we’ve illustrated, our organization’s responsiveness and bottom lines.

Solving the Content Problem Through Application Architecture

This problem is very similar to another problem:  Websites.  Waaaaaaaaaaaaay back in the 1990’s people built and maintained entire websites in HTML by hand.  You had to be a programmer who understood the markup and how to update it and ultimately deploy it to a server once complete.  This model didn’t work. Once business started using the web to communicate to the masses marketing departments started getting involved.  Marketers wanted constant updates. Developers wanted to write code, not update copy.  They needed a solution.  The Web Content Management System (WCM for short) was born.  WCM offered a new architectural solution to manage websites. WCM allowed the developers to put the code into templates that contained placeholders for the content and gave authors a user interface to manage and edit the content at any time.  The content is managed separately from the code (the templates) and the two are brought together to create the final product. Everyone wins.

We need the same capabilities that WCM provides but for our applications.

Why Not Use a Traditional CMS?!

Simple.  Traditional CMS platforms have the wrong underlying design. Most CMS platforms were built or are based on the same design as CMS’s that were built 20 years ago.

  • They were built to manage pages:  Most CMSs do not have a generic concept of what content is.   These systems were built to manage pages.  You might be able to contort the system to get what you want from it but it will be a hack. You need a CMS that is agnostic to the kind or type of content you need to manage.
  • They rely on the wrong type of data tier: RDBMS/SQL databases were the primary backends for data regardless of the problem and open source options like MySQL were readily available.  You need a CMS that leverages a data tier that is more distributed and flexible.
  • They are built on the wrong technology: Many CMS platforms are built in PHP.  That’s fine for certain use cases. But frankly, Java has a larger community, more library support and a lot of powerful platforms like Solr, Elastic Search, Hadoop (and many others) that plug into a Java CMS perfectly.  Why run multiple tech stacks to accomplish a single goal?
  • They aren’t secure: Most CMS platforms couple authoring and delivery together in a single database.  That means work in progress (like pending policy updates) is available in the delivery runtime to anyone who finds a way into the database.  That can spell disaster in the event of a hack. Large companies and governments have suffered expensive and dangerous leaks due to this kind of coupled, insecure architecture.
  • They don’t support multi-tenancy: Most of the CMS platforms out there are not multi-tenant.  If you’re going to back apps with a CMS you need a CMS that will let you properly segregate and secure content between apps.  No one wants to do a CMS install PER app.
  • They don’t scale:  RDBMS is hard to scale.  You either cluster or replicate.  Both have serious issues when it comes to really large, global and auto-scale type deployments.  Supporting an app with your CMS will demand scale. Design for scale from the start.
  • They don’t fit into your development tools and process: When most CMS platforms were designed the content authors were the only audience that mattered.  Today it’s different.  Developer tasks like managing templates, CSS, JavaScript, content models and other artifacts need to be just as easy — and it needs to fit in with your existing workflow.  That means Git source code management, Continous Integration (CI), Integration with your IDE, the ability to fork and support multiple teams simultaneously.

If Not Traditional CMS, Then What? A Modern CMS, That’s What!

To get different results you need a different design.  You need a modern CMS:

  1. Built with the right technologies like Java, Spring, Groovy, Solr, Git.  These are the technologies that will be easy to hire for, will fit into and integrate with any enterprise and will have the out of the box capabilities and horsepower to back any scale deployment.
  2. Decoupled architecture that cleanly separates authoring and content delivery responsibilities on to separate, independently highly securable, highly scalable infrastructures by a publishing process.  Decoupled Architectures don’t have work in progress outside the firewall.  They are much easier to scale.
  3. Built on scalable document-oriented data tiers like XML+disk/Git and Casandra and others.  Disk-based tech is much better for streaming rich content and support global distribution better because they don’t need to be clustered.  At a minimum, you want something that’s document oriented and that distributes globally better than a than a SQL backend RDBMS.
  4. Content type agnostic:  From strings to web pages, to videos and virtual reality experiences.  The CMS needs to accept any kind of content.  That comes down to how content is modeled and how it’s stored.  Does the CMS store content in a SQL database or a JCR repo?  Red flag.  Can’t provide Headless Content / APIs AND rendered content?  Another Red Flag.
  5. Is Multi-Tenant. You need to be able to support many customers/apps on a single install. Either you support it or you don’t and today it’s a must!
  6. Supports authors AS WELL AS developers and DevOps. Developers don’t want to work in some clunky CMS.  They want to work locally in an IDE, then be able to work with their team and ultimately go through the entire workflow out to production.  A modern CMS gives them this.
  7. Open Source.  Open is better than closed. The debate is over. Is it a must?  No. But you’ll get more for your money and you’ll get a lot more innovation at a faster rate if you leverage open source.

Where can I find a Modern CMS?!

Check out Crafter CMS!  Crafter CMS is a modern, 100% open source Java based CMS built on Git!  It’s easy for authors, Amazing for developers and Awesome for DevOps!  Crafter doesn’t sit on a SQL database or a JCR repo like so many CMS platforms out there.  It’s built on Git, Java/Spring, and Solr.  It brings the power Git to CMS!  Authors have true versioning.  Developers and DevOps can work they way they are used to, with the tools they are used to based on the technologies they already know.  Crafter CMS is 100% content type agnostic, highly secure, high performance and scales like nothing else.  If you’re building any kind of application or digital experience, you have content, and you NEED Crafter CMS.  Great experiences are crafted!

 

Responsive vs Adaptive Web Design: Better Together

Responsive web design (RWD), the ability for your web application to “respond” to the size of the view port (traditional screen size vs mobile screen size) is common place and practice today.  Responsive design leverages client sidefront end UI frameworks to hide, show, stack, shrink and grow elements on the screen in a way that is appropriate for the size of the device’s screen.  In essence, it is many user interfaces in a single code base.

Adaptive web design (AWD), a (seemingly) alternative approach to RWD is a server side capability to respond to the client with completely unique templates / markup for a given device type (amongst other facets.)  Adaptive design, while extremely powerful is somewhat less common in part because it relies on a server and is thus a less general technology. It’s also less prevalent in part because, for a large class of problems, RWD is “enough” to get the job done.  However, as complexity and sophistication of requirements mount, adaptive design starts to show clear advantages over a purely responsive approach.

Responsive design and adaptive design are often thought of as an either/or architectural choice.  There is clear overlap in the problems they address and each approach has clear strengths and weaknesses over one-another.  Let’s take a quick look at a side by side comparison:

Comparison

Technical Approach

Responsive Design: Leverages server agnostic front end frameworks (eg. Twitter Bootstrap) to render a appropriate content flow for the given screen size.

Adaptive Design: Leverages back-end server templates (e.g. Crafter CMS) to render distinct markup for the device and context requesting the application.

Strengths

Responsive Design:

  • Mainstream approach with many frameworks that can be applied to any backend technology.
  • Single code base

Adaptive Design:

  • Truly unique markup can be delivered based on any kind of context (not just screen size.)  This means it’s much easier to deliver contextual functionality to your users.  Example:  A retail store .com site that has a traditional marketing website at mystore.com but once it’s detected that a user is inside a physical store location, it gives them a personalized in-store assistance to enhance their shopping experience.
  • Performance.  With AWD you send only the data you need for the experience you are delivering.  On slower, mobile networks that can make a big difference.

Weaknesses

Responsive Design:

  • Single code base.  The more variations you want to support, the more code and complexity there is in that single code base.  This can get out of control.
  • Performance can be an issue:  RWD sends all of the code for all variations to every consumer whether or not they will see it in their flow or not.  If the amount of code is significant, this can lead to a performance hit on slower/mobile networks.
  • It’s difficult (although not impossible) to address different contexts beyond screen size with Responsive design.  RWD was really intended to different screen sizes (view ports.)  Stretching its role beyond that takes the technology out of its wheelhouse.

Adaptive Design:

  • You need a server backend to support AWD.
  • Instead of a single UI design and template code base, you potentially have many.  If you don’t manage and factor the code properly it will be more difficult to maintain.

Opportunities

Responsive Design:

  • Provides a usable experience on any screen size.

Adaptive Design:

  • Provides a usable experience on any screen size.
  • Provide faster experiences for your users.
  • Allows you to truly contextualize the experience.  Device type/class/screen size is really just the tip of the iceberg.  Once the server is involved any type of contextual data (location, previous use, time of day, etc) can be used to deliver unique and relevant experience/features to the user.  That can be huge.

Threats

Responsive Design:

  • If requirements go beyond screen size, RWD may not be the appropriate solution.
  • If the number of variations is too high performance and code complexity may be an issue.

Adaptive Design:

  • Managing unique templates is a heavier approach that requires server technology and the skills to go along with it.

Better Together

While RWD and AWD are most commonly looked at as competitive approaches, the simple fact is that they are not.  These two approaches are in fact mutually exclusive with another and can be combined to acquire the benefits of both.

Responsive design is front end technology.   Adaptive design is backend technology.  Combine them.

Consider leveraging Adaptive design to drive truly unique and contextual markup to the user for what they are doing, on the device of their choice at that moment.   Allow the front end to leverage Responsive frameworks to make sure those experiences flow nicely on a given device.  For performance and code maintainability, as your RWD code grows in complexity and size, consider breaking it down in to smaller code bases that can be individually delivered to a device by RWD (the server.)

A simple example of this is to have AWD templates for Small, Medium and Large screens.  Each with their own unique features and markup.  When it comes to the specifics like an iPhone vs a Galaxy smart phone (both considered small), RWD steps in to make the minor adjustments required to provide a perfect fit for the given device type. This makes the code more maintainable and more importantly it makes the user’s experience much more zippy.

 

Web CMS Architectures: Coupled, Decoupled, or Headless?

Generally speaking there are two main types of Web/Experience Content Management System (CMS) architectures: coupled and decoupled.  Historically the term “coupled” has referred to the relationship between the authoring tools and content delivery of your live site.  With the introduction of headless CMS platforms the landscape has become a bit more complicated.  Are headless CMS’s the new decoupled CMS?  Let’s explore.

Headless CMS

Headless CMS technology provides content to the presentation tier (or content consumer) as a service, typically via a RESTful interface in JSON or XML format. This is known as Content as a Service (CaaS.)

 

The main advantage of a headless CMS (CaaS) architecture is that content is written and published once but  can be requested and presented uniquely by any number of different channels / content consumers.

Coupled vs decoupled

The classic example of a coupled CMS architecture is a blog engine. In a coupled system, the underlying store for your content serves both authoring and delivery.  Your authoring capabilities are part of the live delivery system but are available only to those who have permissions.  In a coupled system, the process of making content live is typically a matter of setting a flag in the database.

A decoupled system by contrast is one that puts authoring and delivery in separate applications, and potentially, on separate infrastructure. In a decoupled system, the process of making content live is done through a publishing mechanism where content is pushed from the authoring platform (and underlying content repository) to a content delivery infrastructure.

So which approach is the right architecture? The reality is, there is no single right or wrong answer.  The answer depends on context: alignment with your requirements, your business process and your business goals.  The topic of coupled vs. decoupled is not a new one.  It’s a debate that has been going on for a long time and will continue to go on so long as there continues to be Web CMS platforms, “fan boys” and a perception that one size fits all.  The more appropriate way to approach the question is to analyze the strengths and weaknesses of each approach and then to consider these in the context your own specific use cases.  We’ll see that in different scenarios we come to different conclusions on which architecture to use.

Coupled architecture

Let’s take a look at the strengths and weaknesses for a coupled CMS architecture.

Strengths

  • Easy to setup and deploy a single instance.
  • Authoring and delivery are on the same infrastructure which can make it easier to build cohesive authoring tools.
  • Relatively easy administration of production system for single sites

Weaknesses

  • SLAs (Service Level Agreements) are coupled — meaning that authoring has to be just as available as the live site.
  • Coupled infrastructures are generally more complex to scale, as they typically depend heavily on database scalability.
  • Content is typically captured in a database schema meant for delivery on the site.  This can make integration and migration difficult.
  • Software complexity is higher because the code base contains both authoring and delivery concerns.  All but the most trivial CMS projects involve some development, and thus becomes an development issue.
  • Pushing content in and out of the CMS to and from third parties takes place in the same system that runs your live site.  Integration is not native to the architecture and it may impact the system’s performance.

Decoupled architecture

Let’s take a look at the strengths and weaknesses of a decoupled CMS architecture.

Strengths

  • Easier to scale for high traffic websites, and to handle multi-site management.
  • SLAs are decoupled.  Authoring can be down for upgrades without impacting delivery. The reverse is also true.
  • Scale only the components that you need.  If you are not adding more authors then there is no need to scale out authoring.  This affects the complexity of the solution and also license costs where they are involved.
  • Code complexity is isolated within each of the two components (authoring and delivery).  Each piece can be as simple or complex as is needed without impacting the other.
  • Integration is a built in concept, as content is natively published to a the remote delivery system, it is generally straightforward to push to other systems as well. Also note, integration takes place on the authoring tier safely away from the live site protecting stability and performance.
  • Content migration and sharing with other systems is generally much more innate to the architecture.
  • Multi-channel support by nature, as publishing to mobile apps, social channels, and other digital channels is a natural extension of the native publishing capability.
  • Content sharing and syndication are more naturally supported.
  • When complexity is isolated and scaling is simple, it’s easier to develop and deploy rich features to your users.
  • Integrating with devOps is much easier.  When you need to integrate your development tools, process/automation and source code repository you are inherently entering in to a discussion about security and systems administration — all of which are significantly more approachable if authoring and delivery systems are separated.

Weaknesses

  • Setup has more components and can be more complex.
  • Publishing introduces additional points of failure.
  • Sub-division of components can go too far driving up complexity and driving down the cohesion of the user experience.

Is a headless CMS a decoupled CMS?

While a headless CMS architectures do “decouple” content and presentation, they do not dictate anything about the publishing capabilities of the CMS.  And while decoupling content and presentation is certainly one of the most important things you can do architecturally, as we can see above, it’s not the only major architecture decision you need to consider. Therefore, it is important to maintain the traditional use of the word decoupled CMS as it relates to separation of authoring and delivery capabilities.

A headless CMS can either be coupled or decoupled.

Further, any CMS worth its salt today, (decoupled or not) must be support headless/CaaS based content delivery.

Making a choice between coupled and decoupled CMS

It’s clear that each approach has its own strengths and weaknesses.  A coupled approach may work really well in one scenario while a decoupled approach may be much more appropriate in another.

Our analysis reveals that a coupled architecture can work well for web apps, mobile apps, and other content-backed digital experiences that need to be set up and put on line in short order and that do not need to be able to scale quickly or to publish content beyond the website itself.  On the other hand, we see that a decoupled architecture is ideal for websites / content back ends that require high levels of availability and performance, need a lot of tailored functionality, must be integrated with third party business systems and must publish to one or more digital channels beyond the website itself.

Crafter CMS

Crafter CMS is a decoupled CMS that separates authoring and publishing capabilities into their own subsystems in order to achieve the many benefits discussed above.  Crafter CMS makes it easy for authors to create, manage and deliver content in any format from RESTful APIs/JSON, to HTML5, and even virtual and augmented reality via AFRAME. So for modern digital experiences that must be delivered across many channels, Crafter CMS provides a decoupled architecture combined with Content as a Service capabilities.