Web Content Management

The Application Server provides the runtime for the Cloud CMS Web Content Management solution. Web Content Management is a term that enterprise vendors have been using for years to distinguish between the role that a CMS (content management system) plays for an organization - it may be used to collaborate around your internal documents, legal records, digital assets and many other content items in addition to your web and mobile content.

Cloud CMS provides a Web Content Management solution that lets editorial teams make changes to web pages, web templates, and web content within the user interface and then instantly preview and publish those changes.

The Cloud CMS Application Server provides out-of-the-box rendering of all of these assets so that you don't have to do any heavy lifting to get things to work. You are, however, free to use your own front-end if you choose to.

This document covers the configuration options for services within the Application Server.

Enable WCM

To enable WCM (Web Content Management), add the following configuration block to your start() call:

{
    "wcm": {
        "enabled": true
    }
}

With WCM enabled, requests will route through middleware that will query for wcm:web-page instances that define pages and URI routes to bind to. Pages are loaded upon the first hit and are then cached.

When make changes to your Cloud CMS content and those changes include modifications to wcm:web-page instances, an invalidation notification is raised and the Application Server will invalidate the cached pages. The next hit will then reload those pages and they'll be cached once again for speedy delivery.

WCM Caching

By default, every request to the WCM middleware will cause the raw page to be fetched and the template to be processed through the Dust processor. The efficiency of this will depend on how complex your templates are and to what degree they utilize Dust tags that incur work. The more work being done (such as queries back to Cloud CMS), the longer they will take to render. Since all of this occurs at request time, your responses will take longer to generate.

To keep things snappy, we recommend using page caching. Page caching allows the WCM runtime to generate output once and then cache it on disk. If another request comes along for the same asset, the cached output will be served back. Using this approach, the Application Server approaches raw web server speed which is about as fast as you can get.

To enabled page caching, add the following to your configuration:

{
    "wcm": {
        "enabled": true,
        "cache": true
    }
}

Page Renditions

When Cloud CMS web tags execute, they automatically calculate their cache dependencies. Cache dependencies include information about what content items were rendered and what input arguments were required in order to generate the given page cache item. Nested tags calculate their dependencies and then those dependencies propagate up to comprise the overall page output dependency set.

Pages are cached and their dependencies are sent back to Cloud CMS where they are stored as Page Renditions. Page Rendition objects can be retrieved, queried against and invalidated. Invalidation events or other events against the Page Renditions in the Cloud CMS API result in notification events that arrive to the Application Server (via a message queue) and inform the cluster servers to invalidate their physical, on disk assets.

Furthermore, when content items are modified within Cloud CMS, the page renditions that have those content items as dependencies are discovered and automatically invalidated. Thus, as you change content in Cloud CMS, the Application Server automatically invalidates to ensure that the cache does not serve back old data.

Page Fragments

In most cases, the advanced page rendition support that Cloud CMS supports via the Application Server is enough to power web sites. Even complex web sites with page caching dependent on user state or other dynamic variables will benefit from the sensitivity of the page renditioning mechanics and it's automatic dependency calculation.

However, depending on the nested structure of your templates, you may be able to improve the amount of time it takes to generate a full page from scratch. This is done by caching individual page fragments. The Cloud CMS Dust tags support a fragment management capability that lets each tag cache individually. As pages are constructed, if cached page fragments are discovered, they will be utilized for faster output generation.

Suppose you have two pages with two tags on each:

Page A - Query1 and Query2
Page B - Query1 and Query3

When Page A renders, it's dependencies are the union of the dependencies from the tags Query1 and Query2. When Page B renders, it's dependencies are the union of the dependencies from the tags Query1 and Query3.

Suppose now that we make a change to a content item. The change to the content item triggers an invalidation event. The API figures out which pages and fragments are affected. In this case, it may determine that Query3 is affected. In turn, Page B is affected.

Thus, the API signals the Application Server to clear cache for Query3 and Page B.

When the next hit comes along to Page B, the Application Server won't have anything in cache. So it will set about building the output by executing the Dust template for Page B. The Dust template will in turn process it's tags which consist of Query1 and Query3.

• Query1 will find something in cache (it's cached fragment).
• Query3 will render anew.

As such, the total time required to generate Page B the second time around is reduced since Query1 was already cached. It doesn't have to render from scratch.

Suppose Query1 takes 1 second to run and Query3 also takes 1 second to run. If generated from scratch, the total time to generate Page B would be 2 seconds. However, with page fragments in place, the total time is only 1 second since Query1 simply reuses it's cached value.

To utilize cache fragments in your Dust templates, simply add the fragment parameter to your tags.

For example, here is a Dust tag that queries for articles within Cloud CMS:

{@query sort="title" skip="0" limit="5" type="custom:restaurant"}
    ...
{/query}

And here is one that caches it's fragment:

{@query sort="title" skip="0" limit="5" type="custom:restaurant" fragment="restaurants"}
    ...
{/query}