CMS for SPAs Tutorial: Using React and Node JS with Crafter CMS

The most traditional, full-featured CMS platforms are not designed to handle headless content and most headless CMS platforms aren’t full-featured and have only basic authoring support.

Crafter CMS is both full-featured and fully supports headless CMS capabilities. That’s pretty unique. In this tutorial, you will learn how to create a content-rich, ReactJS-based Single Page Application (SPA) with in-context editing and other full-featured authoring capabilities.

Our React Application

We need an application to base our tutorial on. For our example we have the following criteria:

  • An existing, open source application that serves a content-rich use case where the content in the application is likely to be updated regularly by non-developers.
  • The application is sophisticated enough to be interesting but not too complex to be understood.
  • The application looks good and is responsive.
  • The application is based on React JS.

With these criteria in mind, I found this terrific open source React-based shopping cart application by Jefferson Ribeiro: https://github.com/jeffersonRibeiro/react-shopping-cart, Thanks, Jefferson!

We’re going to break our tutorial down into a number of broad steps:

Step 1: Download and run the application locally. First, thing’s first let’s get our local application development environment (React and NodeJS) up and running. Here we’ll see that the application already relies on a RESTful service to acquire its content.

Step 2: Create a project in Crafter CMS and set it up to preview our React application running in Node JS. Now that our application is running let’s get the CMS set up and previewing our application.

Step 3: Model a product in Crafter CMS. We have an application and we have a CMS. It’s time to connect them. Here we’ll learn how to model content and we’ll do some minor configuration along the way to customize the Studio UI for the use case.

Step 4: Create a basic RESTful service. Now that we have content, we can create a RESTful service to return the content from the CMS as JSON. Once our service is in place we’ll modify the application to consume our service instead of the service it uses out of the box.

Step 5: Extend the service to include images managed by authors. The out of the box application uses statically managed images and convention. We’ll add images to the CMS to demonstrate extending our content model and app.

Step 6: Add in-context editing to the solution. Now that the app’s content is driven by the CMS we want to make it easier for the content authors to find and edit their content. Making content editable directly through the app is one of the best ways. In this step, we’ll make the small modifications and configurations necessary to support this.

Step 7: Considerations for operationalizing the solution. Now that we have a working solution we’ll talk through some additional thoughts around development process integration and production operations.

Let’s get started!

Prerequisites for the Tutorial

  • NPM / Yarn installed
    • NPM will help you easily download the proper dependencies. You can also use NPM or Yarn to build and execute your application.
    • In our example, I will use Yarn to manage my package.json file and to assist me in building my application.
  • Access to a running Crafter Studio instance.
    • You will need access to create a site and modify its configuration.

Step 1: Download and run the application locally

The first step is to download the application and make sure we’ve got a local environment that will allow us to modify and run the application. This step does not involve the CMS. In many ways, it emulates a common real-world scenario in which the need for authors to modify content without the help of develops is discovered late in the development process or even post-launch. Let’s begin.

  1. On your local machine clone Jefferson Ribeiro’s project: https://github.com/jeffersonRibeiro/react-shopping-cart,
  2. Change directory into the react-shopping-cart folder that was created and run yarn install
    This will install the libraries necessary to run your application.
  3. Run the React application by executing yarn start.
    This will start a NodeJS and run the react application.
  4. Open your browser to http://localhost:3000

This application is pulling content for the product catalog in a JSON feed format from the following URL:https://react-shopping-cart-67954.firebaseio.com/products.json

Step 2: Create a project in Crafter CMS and set it up to preview our React application running in Node JS

Now that our application is running let’s get the CMS set up and previewing our application. The first thing that you need to accomplish this is a running instance of Crafter Studio, the authoring component of Crafter CMS. You can learn how to get this set up here.

  1. Log in to Crafter Studio as the administrator and on Site Dashboard, click the Create Site button.
  2. Following the picture above, populate the dialog. Give the site an ID and select “Empty” blueprint then click the Create button.  Once complete, you will see your empty site previewed in the Crafter Studio application.  Now we want to tell Crafter Studio that our application is not running in Crafter Engine, but instead on NodeJS @ port 3000.
  3. Open the sidebar by clicking the Sidebar button in the navigation.  Then navigate to the site configuration panel by clicking on the Site Config item in the Sidebar menu.

  4. Open the main Studio configuration for the site by clicking the Configuration menu item then selecting the Site Configuration option in the drop-down.
  5. Add the following tag (<previewServer>http://localhost:3000</previewServer>) to the configuration as shown below and then click the Save button.
  6. Click on the Crafter logo up in the upper left-hand corner to return to the dashboard.
  7. In the Sidebar, open Pages and click on Home Page and you will see your site that is running in NodeJS within the preview window of Crafter Studio. At this point, we have both our application (running in NodeJS) and our CMS running with the ability to preview our application.  That means we can continue to use our standard development tools and practices for the React application while integrating it into the CMS.

Step 3: Model a product in Crafter CMS

Now that the two main components (our app and our CMS) are up and running it’s time to connect them.  To start we need to describe the structure of our content, in this case, a product.  To understand what the app is looking for we can examine the UI or because we already know the application is reading a RESTful JSON API from Firebase we can look at that.

Step 3 A: model the content


It’s clear that each product has a title, a description, a style, a price and so on.  To model these in the CMS we must add a new content type.

  1. Open the Content Type administration tool by opening the Sidebar and clicking on the Site Config item within the Sidebar. In the Site Config panel, click the Content Types item, then click on Create New Type
  2. Fill out the dialog by labeling the content type “Product“, select “Component” for the type and then click the Create button.  Once you click create you will be taken to the schema editor.
  3. Drag and drop the controls and from the Controls area to model the product.
  4. Remember to set property values for each control including constraints. To configure a control: click on it and its properties will appear in the property sheet on the right.

  5. Note that for our product sizes I chose to give the author a list of sizes to click on.  Since a product may come in many sizes I’ve used a group checkbox control.
  6. Group checkboxes require a data source.  To keep things really simple let’s supply a static list of sizes with the key-value data source.  Drag the data source from Data Sources and drop it on the form editor under the purple data sources region.
  7. Click the Options property in the data source and then add a row for each option as shown above.
  8. Remember to hook the data source to the control.  To do this, click on the group checkbox control and find the Data Source property.  Select your data source.
  9. Once the model is complete, click the Save button at the bottom of the screen.
  10. Create a content and the sidebar config.

Step 3 B: Configure the UI for Products

Once you save your content type it will be available for content authors to use it.  Studio does this automatically. That said, the more tailored the UI is for your content authors, the easier it will be for them to use it.
Note that this step is not necessary to complete the integration but it does make a difference for authors.

  1. If you click the Crafter CMS logo, you will be taken to the dashboard.  Open the Pages folder on the Sidebar and note that you can right-click on the Home page.  In the drop-down menu, you will find an option for “New Content” as shown below.
  2. Click on the New Content option and you will see your new content type as shown below.A product doesn’t really map to any of the out-of-the-box content folders.  It’s not a page and it’s not a component.  What we want is a unique store just for products.  Cancel the create operation and let’s set up a folder for products and then tie the product content type to it.
  3. Using the Sidebar, navigate to the Site Config panel and then to the Configuration tool.
    Select the Sidebar Configuration tool.
  4. In the configuration, you will note the various modules shown in the Sidebar navigation.  Add a new module block as shown below for products.  You’ll note that at first, we’ll “root” the folder at “/site.”  We’re going to change this later but for now, setting it up this way will allow us to create additional folder structure within the CMS.  Add the module configuration snippet and click the Save button.

    <modulehook>
      <name>wcm-root-folder</name>
      <params>
        <label>Products</label>
        <path>/site</path>
        <showRootItem>true</showRootItem>
        <onClick>preview</onClick>
       </params>
    </modulehook>
  5. Once complete, navigate back out to the dashboard via the Crafter CMS logo and open the Sidebar.  You will find your new Products folder displayed.
  6. Open the products folder, right-click the site folder and then click the New Folder option.  When prompted for a name, enter products and click the Create button.
  7. Now, return to the Sidebar Configuration.  Let’s update the folder so that it shows only the products.  We do this by modifying the path parameter for the module.  Further, we’ll add some custom icons to help visually differentiate the folder within the sidebar.

    <modulehook>
      <name>wcm-root-folder</name>
      <params>
        <label>Products</label>
        <module-icon-open>
          <class>fa-shopping-bag</class>
        </module-icon-open>
        <module-icon-closed>
          <class>fa-shopping-bag</class>
        </module-icon-closed>
        <path>/site/products</path>
        <showRootItem>true</showRootItem>
        <onClick>preview</onClick>
      </params>
    </modulehook>
  8. Now let’s update the Studio Site config so that Studio better understands the content found under the /site/products path.  In the Configuration tool open Site ConfigurationAdd configuration under folders and patterns as shown below:
    
    
    <folders>
      <folder name="Pages" path="/website" read-direct-children="false" attach-root-prefix="true"/>
      <folder name="Products" path="/products" read-direct-children="false" attach-root-prefix="true"/>
      <folder name="Components" path="/components" read-direct-children="false" attach-root-prefix="true"/>
      <folder name="Assets" path="/static-assets" read-direct-children="false" attach-root-prefix="false"/>
      <folder name="Templates" path="/templates" read-direct-children="false" attach-root-prefix="false"/>
    </folders>
    ...
    <pattern-group name="component">
      <pattern>/site/components/([^&lt;]+)\.xml</pattern>
      <pattern>/site/products/([^&lt;]+)\.xml</pattern>
      <pattern>/site/system/page-components/([^&lt;]+)\.xml</pattern>
      <pattern>/site/component-bindings/([^&lt;]+)\.xml</pattern>
      <pattern>/site/indexes/([^&lt;]+)\.xml</pattern>
      <pattern>/site/resources/([^&lt;]+)\.xml</pattern>
    </pattern-group>
  9. Once you save this file and return to the dashboard or preview you will note that Products now has its own icon and when you open it, it is specifically rooted in the products folder in the repository.
  10. Modify the content types to tie them to the IA.  An author should not be able to create a product anywhere except under products.  Other content types may also be tied to specific folders.  Let’s look at how we can configure this.In the content type editor for a product, under the Basic Properties for the type, find the Configuration Property.  Click the pencil to open the editor for the configuration.
    Add the following XML snippet to the content type configuration:

    <paths>
      <includes>
        <pattern>^/site/products/.*</pattern>
      </includes>
    </paths>


    Open the other 2 content types and add the following snippet.  This snippet hides these types because it does not make sense for authors to be able to create new objects of these types.

    <paths>
      <includes>
        <pattern>^hidden</pattern>
      </includes>
    </paths>
  11. Navigate to the dashboard and try to create content in the products area.  If the previous steps were performed correctly the form for the Product content type will be automatically launched as soon as you click the New Content button.  Studio understands (based on the configuration) that this is the only type that is allowed to be used here and thus defaults to it.

    The form will automatically open:

 

Step 3 C: Create Product Content

Now that your authoring tools are set up to make it easy to add products it’s time to create some product content.  Using the New content option, and following the content on the site (or in the JSON response) create at least two products by right clicking on the product folder then filling out the product form and saving.


  1. You can easily create new content by right-clicking on the products folder and selecting the New Content option.
  2. Create as many products as you like by filling out the Product form and clicking the Save and Close button.  You will need at least 2 products for the example to work well.

Step 4: Create a basic RESTful service

Now that we have content, we can create a RESTful service to return the content from the CMS as JSON. Once our service is in place we’ll modify the application to consume our service instead of the service it uses out of the box.

Step 4-1: Create the Service

Crafter allows us to easily create RESTful services through scripting.  By putting the Groovy script in the right location with the right naming convention we define an RESTful endpoint. https://docs.craftercms.org/en/3.0/developers/projects/engine/api/groovy-api.html

  1. In the Sidebar, open the Scripts folder and then open the rest folder.
  2. On the rest folder right click and choose Create Controller option.
  3. Provide your service name and http method you want.  In our case our service is going to return products so our service name is “products” and the HTTP method the service will respond on is a GET so we append .get to the name.
    1. This is a convention in Crafter CMS.  Under the rest folder we can create any number of sub folders and the file name of the RESTful endpoint is named by the script as NAME.HTTPD_METHOD.groovy.
    2. all standard request methods are supported ex: get, post, put, delete,
  4. Click Create and then supply some basic code in your controller as shown below.
    This code will result in an object with an empty products array.  By returning the result value at the end of the script Crafter knows to marshal this object in to JSON for us when the service is invoked via the URL.
  5. Test the service.
    1. Go to http://localhost:8080/api/products.json in your browser and you will see the JSON representation of the object returned by the script.
  6. Now we that we see our service working we can update it to return the content we want in the structure we want.
    1. Right click on the controller and then click Edit.
    2. Update the code as show below.
def result = [:]

def queryStatement = 'content-type:"/component/product"'

def query = searchService.createQuery()
 query = query.setQuery(queryStatement)
 // limit returned fields if you like
 //query.addParam("fl", "localid:cmsId,sku,title,style,description,price,installments,freeShipping,sizes.item.key")

def executedQuery = searchService.search(query)
def itemsFound = executedQuery.response.numFound

result.products = []

executedQuery.response.documents.eachWithIndex { document, idx ->
 def product = [ 
 id: idx,
 cmsId: document.localId,
 sku: document.sku, 
 title: document.title, 
 style: document.style,
 description: document.description,
 price: getPrice(document),            // potentially get the price from external system
 installments: getInventory(document), // potentially get inventory from external system
 isFreeShipping: document.freeShipping,
 availableSizes: document["sizes.item.key"],
 currencyId: "USD", // hard code USD for now
 currencyFormat: "\$", // hard code currency format for now
 ]
 
 result.products.add(product)
}

return result

def getPrice(document) {
 // simple example of abstracting where price comes from
 return new Float(document.price)
}

def getInventory(document) {
 // simple example of abstracting where inventory comes from
 return new Integer(document.installments)
}

 

The code above makes a query to Crafter Search / Solr and then iterates over the results to format, structure and possibly embellish them with additional data.  Note, that if there is no need to restructure or augment the results differently than the Solr response the results could be returned directly without any additional code.  Simple field name mappings can be done with the fl query parameter.

7. Invoke the response and confirm it now meets the structure and contains the content that the application expects.

Go to http://localhost:8080/api/products.json in your browser and you will see the JSON representation of the object returned by the script.

Step 4-2: Modify the App to use the Service

Now that we have a service which dynamically provides the products that are created and edited/managed by the authors in the CMS we can update our React Application to use it.

To do this:

  1. Change line 5 in src/store/actions/productActions.js to

    const productsAPI = "/api/products.json"
  2. Add the following to package.json
    "proxy": {
      "/api": { "target": "http://localhost:8080" },
      "/studio": { "target": "http://localhost:8080" },
      "/static-assets": { "target": "http://localhost:8080" }
    },
  3. Preview the application at http://localhost:3000
    Note the content showing in the store is from the CMS

Step 5: Extend the service to include images managed by authors

The out of the box application uses statically managed images and convention. We’ll add images to the CMS to demonstrate extending our content model and app. This step is optional and is simply meant to show how you can extend the functionality if choose.

  1. In the product content model:
    1. Add image pickers for both large and small images
    2. Add a data source for picking images from the desktop.
    3. Configure the data source to put images in /static-assets/images
    4. Click on the image picker properties and connect the data sources to the image pickers
  2. Test the forms by updating your products with image content.
  3. Update your RESTful product service to return image values.

    def product = [ 
     id: idx,
     cmsId: document.localId,
     sku: document.sku, 
     title: document.title, 
     style: document.style,
     description: document.description,
     price: getPrice(document), // potentially get the price from external system
     installments: getInventory(document), // potentially get inventory from external system
     isFreeShipping: document.freeShipping,
     availableSizes: document["sizes.item.key"],
     currencyId: "USD", // hard code USD for now
     currencyFormat: "\$", // hard code currency format for now
     largeImage: document.largeImage,
     smallImage: document.smallImage
    ]
  4. Update the application to pull the images from the service rather than assume their location in the application.
    1. Update the file src/components/Product.js line 34
      <Thumb
       classes="shelf-item__thumb"
       src={product.largeImage}
       alt={product.title} />
    2. Update the file: src/components/Thumb.js
      import React from 'react';
      import PropTypes from "prop-types";
      
      
      const Thumb = props => {
       return (
       <div className={props.classes}>
       <img src={props.src} alt={props.alt} title={props.title} />
       </div>
       );
      };
      
      Thumb.propTypes = {
       alt: PropTypes.string,
       title: PropTypes.string,
       classes: PropTypes.string,
       src: PropTypes.string.isRequired,
      };
      
      export default Thumb;
  5. Preview the application at http://localhost:3000
    Note the content showing in the store is from the CMS

Step 6: Add in-context editing to the solution

Now that the app’s content is driven by the CMS we want to make it is easier for the content authors to find and edit their content. Making content editable directly through the app is one of the best ways. In this step, we’ll make the small modifications and configurations necessary to support this.

  1. Note that in our service we are returning a property called cmsId.  This property will be used by the app to identify the content that the editing tools will be associated with.



6.1 Indicate Where the In-context Editing Regions “Pencils” Belong

To enable point and click on content editing on content, you must indicate where the regions are and what content the regions relate to. To do this in HTML5 applications Crafter Studio (and the Guest library) uses HTML5 attributes.

The following attributes are used:

  • data-studio-ice: This property marks the element as the container for in-context editing. No value is required.
  • data-studio-component-path: This is the path of the content object. Example: “/site/products/a-component.xml”
  • data-studio-ice-path: This is the path of the content object. Example: “/site/products/a-component.xml”
  • data-studio-component: This is the content type name. Example: “/component/product”

Example Container element:

<div data-studio-component-path=”/site/products/a-component.xml”
data-studio-component=”/component/product”
data-studio-ice=””
data-studio-ice-path=”/site/products/a-component.xml”>
INNER HTML
</div>

  1. Update the application to pull the images from the service rather than assume their location in the application.
    1. Update the file src/components/Product.js line 34
      <Thumb
       classes="shelf-item__thumb"
       src={product.largeImage}
       alt={product.title}
       cmsId={product.cmsId} />
    2. Update the file: src/components/Thumb.js
      import React from 'react';
      import PropTypes from "prop-types";
      
      
      const Thumb = props => {
       return (
       <div className={props.classes} 
       data-studio-component-path={props.cmsId} 
       data-studio-component="/component/product" 
       data-studio-ice="" 
       data-studio-ice-path={props.cmsId}>
       <img src={props.src} alt={props.alt} title={props.title} />
       </div>
       );
      };
      
      Thumb.propTypes = {
       alt: PropTypes.string,
       title: PropTypes.string,
       classes: PropTypes.string,
       cmsId: PropTypes.string,
       src: PropTypes.string.isRequired,
      };
      
      export default Thumb;
  2. Preview the application at http://localhost:3000/studio
    Note the content showing in the store is from the CMS

  3. Turn the pencils on by clicking on the pencil in the main toolbar.
  4. Hover over each product content item.
  5. Click the pencils to edit and the user will get the form where they can edit the content.
  6. Update the content.
  7. Click the Save and Close button. On save the preview will update to reflect the changes.
  8. That’s it! The preview updates.


Conclusion

 

React has become the de facto way to build highly usable web-based applications.  React helps developers create Single Page Applications that are fast and extremely usable for end users.  When those applications need content that’s managed by business users, developers have turned to headless CMS solutions to supply the content.  Unfortunately, most Headless CMS platforms do not provide full-featured editing tools like in-context editing, preview, and drag-and-drop.  Content editors are used to these tools and when they are missing it can be frustrating.

With Crafter CMS, everybody wins.  Content authors get the experience they are used to.  Developers get the architecture and development frameworks and the process they want.

CMS for SPAs (2 of 4): Save the Content Authors

In Part 1 of the series CMS for SPAs: Are Single Page Applications and Headless CMS a Slam Dunk?  we looked at the trend toward Single Page Applications (SPA) and Headless Content Management Systems (CMS) in general. SPA applications are becoming the de facto way to build web-based applications and sites. Headless CMS is a decoupled, API-first approach to content management that aligns neatly with SPA architecture. Further, the decoupled nature of the architecture makes content more reusable (multi-channel) and completely divorces development from the CMS allowing for greater freedom and agility for developers. While these can be seen as major wins, several developer and DevOps issues remain while others have been created. Further, most of the headless CMS solutions available today set content authors back nearly 20 years in terms of content editing and workflow tooling and practices.

In this installment, we’ll focus on the various ways content authors have been impacted by headless CMS and how Crafter CMS addresses these issues to provide authors with true headless CMS support for SPA applications.

Authors Forced into the Wayback Machine

Clumsy tools and processes for editing, reviewing and testing content offered by headless CMS platforms have content authors, the primary stakeholder of CMS platforms, wondering if they fell asleep and woke up back in the early 2000’s. Let’s take a look at some of the issues facing authors in the Headless CMS space.

Preview and In-Context Editing

Authors are accustomed to easy-to-use tools that enable them to visually locate, edit and publish content in websites or applications. Many headless CMS platforms provide no way for authors to preview their work prior to publishing it. Authors are forced to change content via content entry forms that are completely disconnected from the presentation.  In order to see what the content will look like on the website or in the application, they must publish the content. No author should be forced to work with slow and clumsy deployment iterations just to ensure their content fits and looks good on destination channels. That’s a major step backward.

Some CMS vendors and practitioners argue that by completely obscuring the presentation from the authors, content gets created in a fashion that is naturally more reusable. That’s not necessarily accurate. Content is more reusable when stored and transmitted in a fashion that is divorced from presentation — but that does not mean authors should be forced to ignore how their content will be presented on key channels. As the saying goes: “the medium is the message.” To most authors, the layout is just as important as the content itself. Authors need tools in their headless CMS that are on the level of the tooling they have become accustomed to with more traditional CMS platforms.

Delivering Editing and Preview tools for SPAs

Crafter CMS gives authors a full, interactive in-context preview and editing experience within SPAs. Authors have exactly the same tooling they have become accustomed to with traditional CMS.

Crafter’s preview capability can sit in front of any web-based application. The specific technology does not matter. Crafter’s preview and editing tools are front-end agnostic. One of the key reasons Crafter is able to do this is that Crafter CMS has always separated authoring and delivery into distinct but integrated components. We’ve been assuming a decoupled architecture for years.

Authors are the main users of any CMS and their needs must be properly addressed. A solid authoring experience with true in-context editing and preview is table-stakes for any headless CMS.

Personalization of Headless / API based Content

Another area that Headless CMS platforms have impacted authors is support for targeted/personalized content. Content authors need to be in control of the rules that drive the right content to the right people at the right place and time.

To support personalization your headless CMS must support the following two capabilities:

  • The ability to design, configure or code business rules behind the services.
  • The ability to preview content and functionality driven by personalization rules prior to publishing.

To date, most headless CMS platforms are simple repositories of content that are retrievable by API call. These systems offer no ability to create rules that can be executed based on the request parameter variations and characteristics of the requester.

Further, based on the previous section, we already know that most Headless CMS platforms don’t support pre-publishing preview of content — let alone the ability to preview content and experience as it would appear in different scenarios. There is little point in writing rules or variations of content without the means to properly test them prior to publishing.

Delivering Personalization for SPAs

Crafter CMS provides excellent support for targeted and personalized content even when content is delivered in a headless environment. Authors can configure scenarios and simple rules via the UI or leverage sophisticated rules built-in scripting languages by the development staff. Further, Crafter CMS provides rich preview tools that allow authors to impersonate different users and other types of content consumers within the authoring tools so that content and scenarios can be properly tested well before they are published.

The Need for Real Versioning and Branching

Most CMS platforms (traditional and headless) support some kind of basic versioning.  For the most part that support extends only to a single content item. Each item has its own history.  There is no way to look at the entire content collection at it existed at a specific point in time. That can be a major challenge for authors if they need to reference a previous campaign or support an audit.  The ability to maintain a version history is paramount and rudimentary versioning is typically not enough.

Another key feature that is missing from CMS platforms is the ability to support branches.  Branches allow us to work on different variants of the content at the same time. A branch not only allows concurrent work but it also enables us to sync up variants when it’s appropriate.  This extraordinarily important to authors who are supporting a re-branding or a major content overhaul. Most CMS systems can’t support that without content freezes and manual “double publishes”

Delivering Real Versioning and Branches

Crafter CMS’ repository is based on Git. Git provides authors using Crafter with a versioning system that is multi-file — meaning that an author can see the entire content collection at any moment in time in its history.  Git also provides support for branches which means that authors using Crafter can support difficult operational scenarios like re-brands without any content freezes or extra publishing.

Content freezes and Other Business Interruptions

New features, design refreshes, and integrations are a way of life for today’s customer-focused market. Agility and innovation at scale and speed are key to winning in this competitive landscape. Wherever you have innovation you will find developers and development process along with its procedures, tools, and environments. Businesses want innovation without disruption. Unfortunately with most CMS platforms, due to their architecture, business disruptions are exactly what content authors and other business users end up with. Outages and complicated deployment processes along with content freezes are realities for most innovative organizations use CMS.

When we look at the reason for the disruptions to the business activity we find that the development and testing process requires that we maintain independent testing environments and that we do code deployments. It’s during this maintenance activity that authors are often told to “hold off” or “stay out of the system.” Content freezes waste time and money and they hurt the business. SPAs and Headless CMS platforms do nothing to solve this problem.

In order to get content to lower environments like Dev, QA, and Test we have to take an export of Production. Authors need to stop working during exports. Imports on the lower environments are no fun either. Every environment needs to be painstakingly and individually updated. When coding is complete it has to be rolled out. Once again authors need to refrain from using the system. Complicated deployment procedures and models can take hours, days and in some cases even weeks. More valuable time and money are wasted.

Uninterrupted Business Activities with SPAs

Crafter CMS has an architecture that is different from other CMS platforms. Crafter is designed and implemented with repository technology specifically designed to handle these processes with minimal effort and friction. Crafter CMS leverages Git at its repository layer. In contrast to CMS platforms that rely on databases or JCR repositories that rely on exports and imports that require outages to sync data between environments, Crafter’s repository is meant to be distributed and as such it natively supports syncing between related stores. We call this push button process “Code Forward, Content Back”™ Crafter CMS allows developers along with their tools and process to live and work in harmony with content authors. This enables collaboration together without interruption and with much less friction so that a greater level of innovation and ongoing operations can all take place at the same time.

Conclusion

The net-net of it is simple. Regardless of any improvement in content reusability or ease of development, authors need to be able to do their jobs easily and efficiently without interruption. New tools and approaches need to move the ball forward, not back. Unfortunately for authors, headless CMS has lost major ground.

Some of these shortcomings can be overcome with time but all of the shortcomings we looked at here are architectural in nature. Architecture changes are the most difficult and time-consuming to make. You don’t have to wait for your current headless CMS to correct course. Crafter CMS is an open source headless CMS with the right architecture to take full advantage of the benefits of SPA applications provided to end users and developers while giving authors the tools, process and uninterrupted service they need to succeed.

What has your experience been working with SPAs and your CMS?

CMS for SPAs (1 of 4): Are Single Page Applications and Headless CMS a Slam Dunk?

From web-based applications like Gmail, Instagram, and Google Maps to websites like The New York Times and Facebook, real-world examples of Single Page Applications (SPA) are everywhere you look. Developers have been turning to SPA frameworks and architectures to create better, more usable, richer applications for their users.

Nearly every Content Management System (CMS) out there purports to support SPA frameworks and architectures. In this blog series, we’ll look at SPA use in the CMS space to learn more about what’s working, what’s not and what we can do about it. Let’s jump in.

SPAs are web-based applications built with rich UI frameworks that run client side and use partial page updates rather than full page refreshes to update data, content, and UI. SPAs have several advantages:

  • Great user experience: SPAs make the user experience more fluid with rich UI interactions that leverage asynchronous calls to the server for data and partial page refreshes.

  • Clean architecture: SPAs architecture promotes a clean separation of the frontend application and backend services and data. This approach makes development faster and more flexible.

  • Great frameworks: There are a lot of great frameworks that make developing SPAs faster and easier including React, Angular, Vue and others.

In the CMS space, SPA applications have been a win for developers but content authors have taken a major hit.


Developers have been keen to adopt SPA technology and CMS vendors have quickly responded with support for Headless CMS (also known as Content as a Service [CaaS]) support.

This shift has been highly promoted by CMS vendors because it has a number of advantages with respect to content management. Returning content as JSON or other presentation-less formats makes content more reusable within and across delivery channels. More importantly, by removing the consuming application from the CMS, the approach seems to solve one of the major challenges in the CMS space: development. It’s no secret that most developers have little interest in working within the toolsets and constraints of a CMS. Developers want control over their tools, frameworks, and process. CMS platforms are notoriously framework laden and don’t integrate well with DevOps tools and process.

The headless approach completely and neatly decouples development and content production workflows. On the surface, the headless approach appears to be a perfect evolutionary step for CMS. New delivery channels and integration opportunities show up all the time. In a customer experience driven market, anything that aids development and reduces time to market is seen as a winner.

However, the reality is that decoupling the CMS from the consuming application does not solve long-standing challenges such as refreshing content in lower environments — in fact, it complicates them. Worse, complete decoupling creates new problems. While software development and content production workflows are best divorced, their products: the code and content are not. There is a time/version specific relationship between the data model, the content and the code at any given moment. To illustrate the point: it’s often not possible to “point” an older version of an application at a newer version of the content and vice versa. It’s extremely difficult to troubleshoot or perform legal and regulatory audits without this capability. Yet, with the clear benefits of better products, a cleaner deployment architecture and faster, easier development in mind, the remaining issues are either unrecognized or a compromise many developers are willing to take. For developers, the SPA and headless approach have largely been a win.

The ironic and unfortunate “dirty little secret” in the CMS space of late is that the biggest losers of the headless CMS movement have been the content authors, CMS’s main stakeholder.

Today’s headless CMS options have the following drawbacks for authors:

  • There is no preview. Authors are used to in-context editing and preview. With headless, they are back to working in forms with no preview and are left to hope and a cumbersome process to ensure that the content will present properly.
  • There is no personalization. Marketers want to be able to target and personalize their messaging to the audience. Most headless CMS platforms don’t give them the capability to describe and execute targeting rules much less test and preview the various scenarios.
  • DevOps are still not supported: Despite investments in new technology, tools and process content authors see zero improvements in DevOps activities related to feature releases. Content freezes and outages are still commonplace during feature deployments with headless CMS.

It doesn’t have to be that way! With the right CMS architecture and platform content authors, developers and DevOps can work together on SPA based sites and applications at speed with the tools and processes they are accustomed to (like in-context editing) without stepping on each other’s toes.

A Better Approach to SPAs, CMS and DevOps

Crafter CMS is an open source CMS platform that takes a completely different approach to headless CMS, SPA development and DevOps. Crafter CMS has a very different architecture from traditional CMS platforms that are monolithic and rely on SQL databases and JCR repositories.

Crafter’s architecture is modular, flexible, and completely elastic with a repository and deployment design that is shared-nothing and based on Git. This architecture enables Crafter CMS the flexibility to support content authors, developers and DevOps to collaborate together to build and release new experiences with minimal friction while using the tools and workflows that work best for them.

Crafter CMS is an API first CMS that is:

  • UI agnostic and can support development and editing and preview for any UI framework
  • Capable of supporting rich, personalized headless CMS content
  • Git-based to support your development frameworks, tools, and process in a way that separates development and content production workflows without needing to separate the deployable (code and content) artifacts.

Conclusion

SPA applications combined with decoupled, headless CMS offer significant advantages in terms of end-user experience, development, and deployment. However, it’s clear that headless is not a silver bullet. Completely divorcing the CMS and the consuming application or site creates significant challenges for DevOps, support and other departments. More importantly, the SPA/headless pairing has left authors out in the cold by taking away the process and tools they have become accustomed to over the past decade.

These shortcomings can be addressed with a new breed of CMS architecture. What’s needed is a flexible headless CMS that support proper authoring tools and process regardless of front-end technology. Moreover, we need a CMS that embraces and integrates development tools and process rather than shunning them. That’s exactly what we’ve set out to do with Crafter CMS. Stay tuned for our next blogs in this series where we’ll dive deeper into these concerns and their solutions.

What has your experience been working with SPAs and your CMS?