The SPA-CMS paradox.
Five common myths debunked.
It sounds like a clear-cut project — develop a single-page, real-time car configurator for a global auto maker. Design the database with text and input fields. Build versions in multiple languages. Create the rules, run some tests, and you’re on to the next project.
Clear-cut — until the requests start pouring in. Authors from the company’s regional offices in Canada need to modify the French translation to fit with their dialect. And you’re the only one who can make the changes. The Swedish office has to swap out the image of the red car for a blue one because the first isn’t available for sale in their market. But they don’t have the ability to do it themselves. Edits to content and layout start to pile up.
To keep up with all the changes, you find yourself adding more and more options to your content database so that authors can perform localized changes you never predicted. And with every additional request, you see your days get longer and your evenings shorter. If only you’d thought about how to scale the maintenance of all that content before writing even a single line of code.
It’s a tough situation for any developer. You’re under pressure to deliver content as quickly as possible, but you still have to accommodate content and layout changes down the road.
Instead of turning a single-page application into a nightmare, developers like you have started using modern content management systems to help them make their SPAs more efficient and more valuable.
That’s the power of a hybrid CMS. By combining a traditional CMS with headless delivery such as single page applications, you and your IT team can work closely with marketing authors to deliver interactive experiences like that car configurator a lot faster.
But as a developer with enough languages, frameworks, and systems to juggle, you might have some preconceived notions about working with SPAs and a CMS. Here are five myths that could be preventing you from getting your development projects out the door faster.
Myth #1: SPAs can go it alone.
As a front-end developer, you might believe that you can create SPA layouts better and more efficiently using just CSS, rather than relying on a content management system. And while doing so could help you get your projects completed more quickly, once it’s time to maintain those layouts and the content that goes with them, you’ll likely run into issues that will slow you down in the long run, just like those in the example above.
When marketers have to wait for IT to make content edits, development is slower, content is outdated more quickly, marketers have less input into content look and feel, and the user experience suffers. That’s why authors need the ability to make these changes themselves. By giving them that leeway, you don’t give up your evenings working late just to make a lot of tiny tweaks to your single page application text.
That’s where SPA and hybrid CMS integration comes in. Once you build your single-page application, authors can make changes as they need to, freeing you up to move on to the next great project.
“I liked building things as a developer, but I wanted to be done and move on. I didn’t want to go into maintenance mode, upkeep the app I just built, fix bugs, or make every change that users wanted me to make. If you set yourself up right, you don’t have to be tasked with that.”
Adobe Experience Manager Solutions Consultant Manager, Adobe
Myth #2: The headless way or the highway.
While using a headless CMS to separate the authoring and presentation layers does help you reuse your code across channels and speed up content delivery, authors still need a way to do in-context editing as well as preview the changes they’re making in various distribution channels. This way, they can immediately assess and improve the end-user experience while they’re creating the content.
The problem is, with a headless CMS, authors can’t edit the content in context on their own. And that’s when the requests start. You add them to your sprint, work for a week, do a series of tests, and roll out the changes. Rinse and repeat for every new request.
If you choose a hybrid CMS that includes a SPA editor, marketers can still make and preview layout changes within the framework that you provide to them. Think of it as freedom within a framework. The overlay won’t interact with your code because the SPA is isolated from the editor. And, in production and publish, the editor will never load.
“Most headless approaches don’t let you edit your page in context and preview those edits until you go through your entire build process. Then, if you want to look at another persona, you have to go through the whole process all over again.”
Adobe Experience Manager Solutions Consultant Manager, Adobe
Myth #3: You have to ditch your favorite tools.
The thought of adding a hybrid CMS to your SPA workflow might make you worry about having to learn new tools like Eclipse IDE, or compilation tools you’ve never used before. But as long as your CMS can adapt itself to the architecture of your SPA, you can keep doing everything you normally do with the tools you’re already used to using. Here’s why.
A separation of concerns helps front-end and back-end developers work more efficiently. Just because your SPA is supported by a hybrid CMS doesn’t mean you have to learn a Java platform, stack, or tooling. All of that CMS work is still handled by the back-end developer. The integration is possible because someone in the middle maps the client-side components of your SPA to the server-side components of the CMS, allowing authors to preview and render pages inside the CMS. Ultimately, the only thing that’s pushed to the SPA application is a JSON payload. The rendering of the app is still fully controlled by the front-end developer.
SPA-CMS mapping — three things to remember.
1. Front- and back-end developers should agree on which components to include in the SPA, as well as the JSON model, so there’s a one-to-one match from SPA to back-end components.
2. Mapping isn’t done inside of your component. It’s defined outside. This keeps your code clean, allowing you to reuse your components. Your code is pure React or pure Angular except the mapping, which can live in a different file.
“When you’re a developer, it’s like signing a contract that says I will never be done learning. I think continued learning is an integral part to any good developer’s growth, but things change at such a furious pace that this
can be draining.”
Fullstack Web Developer and Senior Software Engineer, Quandl
Myth #4: Authors will break your app.
Yes, the more power you give to an author, the more they can break things. But marketers have been creating, configuring, and laying out HTML content for years. SPA isn’t any different. The secret is to use strategies and tools to ensure that authors can’t break your app. For example, train certain authors to do layout, implement approval steps, and define template layouts so authors stay within the parameters you’ve defined.
Stop responding to one-off requests for content changes by adding yet another management option to your content database. Instead, let authors have full responsibility for content from the get-go. That way you can contribute value in a way that’s more meaningful to you and your visitors, keep projects moving along, and take back your weekends.
“You don’t want to be in the business of continually building content management options for your marketing department. You want to build something for your customers.”
Product Manager, Adobe
Myth #5: SPA, personalization, and testing don’t mix.
Marketers don’t have the luxury of asking you for development support each time they want to create and push out time-sensitive offers through your website or SPA. Once the request goes through the development process, chances are, the opportunity to run the offer is gone. Traditionally, SPAs required continuous developer intervention to give marketers the ability to run experiments and personalize customer experiences. For years, this has been disruptive for both developers and marketers, slowing down the overall process.
Adobe has found a way to shatter this myth. Using the Visual Experience Composer in Adobe Target, developers can perform a one-time setup to enable marketers to test and personalize their own SPA experiences in a WSYWIG framework. No more interruptions. No more missed opportunities
“If marketers have to rely on IT, it’s not a scalable solution. With the Visual Composer, developers can do a one-time setup and from that point, business users are fully empowered.”
Adobe Target Senior Product Manager, Adobe
Separate fact from fiction.
From car configurators to mortgage calculators, when you’re working to get project after project out the door, even the smallest ask can slow down the whole works. That’s why giving content authors the ability to make and preview their own SPA content and layout changes is so important. By integrating your SPA with a hybrid CMS, you can stick to working with the tools you know, doing what you do best, and delivering content faster to current channels, as well as those that are yet to come. And that’s no myth.
Adobe can help.
Adobe Experience Manager Sites provides a scalable digital foundation that helps you deliver compelling experiences across emerging technologies, including single-page applications. Adobe Target can help you optimize and personalize that content to ensure you’re getting the highest ROI from your content investment.
Find out more about how a digital foundation can help you shatter the myths that slow down your content development projects. This SPA Introduction and Walkthrough can help you get started.
Personal interview, Gabrielle Walt, product manager, Adobe, August 23, 2018.
Personal Interview, Matthew Loewengart, Adobe Experience Manager solutions consultant manager, Adobe, October 12, 2018.
Personal Interview, Nimit Kumar, Adobe Target senior product manager, Adobe, August 27, 2018.
Ryan Johnson, “Always be Learnin’: My Developer Fatigue Story,” Medium, September 24, 2017.
YOUR NEXT STEPS