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?

Great Crafter CMS Webinars

Check out these free pre-recorded online events! Learn more about how Crafter CMS is built and where and how to apply it to your projects!

 

Planning a Smart Mobile App Development Strategy

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.