AEM SPA Editor Demystified

Intended audience: CMS Developers, Architects. 

Pre-requisites: Basics of SPA (Single Page Application). 

It's been a while since Adobe released AEM SPA editor. The support was added officially in SP3 for 6.4. A detailed explanation on how this functionality works is provided by Adobe here. Hence, I will not go into the "How to...” part in this blog. Also, I will not be going into the "SPA" part of it as there are a huge number of blogs and tutorials dedicated to the topic. Instead, I will try to answer some abstract questions (which I had and couldn’t get an answer elsewhere) like:  

1. Why is SPA editor needed at all? What problems is it trying to solve? And how is it solving those problems? 
2. As the name "SPA Editor" suggests, does it just give just editing functionality for Single Page Applications? Was it not there in the first place? What's new here? 
3. Should I use it in my application? If yes, how? 
4. I don’t have much time for philosophical questions. Is it possible to get a quick summary of this blog? 

The last one was not my question, I just added it here as many might have that question after my lengthy introduction. Let me answer the last question first, well, for obvious reasons. Here is the summary: 

Hybrid, SPA without SPA Editor framework	With SPA Editor (6.4.3 +)
Overlap between SPA JavaScript and AEM code. Hence difficult to manage.	Less overlap.
Too much customization would be required to use AEM in a hybrid approach.	Provides hybrid support out-of-the-box
Too much customization would be required for authoring experience when AEM is used in a hybrid approach.	Provides authoring support for hybrid approach out-of-the-box

And for those who have time, before I try to answer the other questions, I need to detour a little from our original agenda. We need to understand the different ways in which CMS is used in the enterprise applications and how it interacts with other entities involved. 

  

1. Traditional Approach 
2. Headless Approach 
3. Hybrid Approach 

  

If you are aware of this classification and the differences between them, feel free to skip this section. 

   

1. Traditional Approach 

In this approach, the content and presentation are strongly coupled. Hence, the content cannot be exposed to a client which wants to have its own presentation logic. Hence, this monolithic approach is not flexible for new age channels like Alexa or similar voice interaction systems. But the authors on the other hand get full control on the application content, look and feel.  

 

1. Headless Approach 

The content is served in a headless manner. "Head" in "Headless" refers to the presentation that the content comes with. When you just want to expose the content and not the presentation, you can use this approach. This is more light-weight and flexible because the content and presentation logic is decoupled. On the downside, authors or business users loose the control on the application. This approach makes the life of a developer easy at the cost of the misery of a business user. 

   

1. Hybrid Approach 

"Best of both worlds" or at least that is how it is marketed these days. This approach decouples content and presentation while giving back the control the business users lost on their applications in the previous approach. Since the content and presentation is decoupled, it is flexible so that the future clients can consume the content independently. In the recent years, many applications are moving to this approach. The separation between content and presentation layer needs to be a logical one rather than physical one. Hence it wouldn't make the approach any less "Hybrid" if the presentation layer resides or hosted inside the CMS. 

  

In addition to the above classification, an application can be built in either of the following 2 approaches: 

1. Single Page Application - Application where only required content is loaded by AJAX calls as a response to a user interaction. 
2. Multi-Page Application - Application where the complete page is refreshed as a response to a user interaction. 

You can read more about SPA's in other blogs and tutorials. There are multiple combinations possible by combining the two classifications. Example: Hybrid, Multi-Page application. Traditional, Single Page Application etc. 

  

Now that we are aware of the different classifications of the CMS based applications, let’s understand the nuances of SPA editor and start answering the questions that I put forth in the beginning. 

The SPA editor feature mostly revolves around one particular type of application that we just discussed. That is, "Hybrid, Single Page Application". To some extent, it also becomes relevant to "Headless, Single Page Application". The name “SPA editor” doesn’t quite make justice to the role that the add-on plays. It’s more like a framework which helps in development of “Hybrid, Single Page Applications”. With this introduction in mind, let’s revisit the questions. 

Why is SPA editor needed at all? What problems is it trying to solve? 

The Sling models, exporter API’s existed prior to 6.4.3 which facilitated exposing content as a service. What is the new problem which SPA editor is trying to solve? As we discussed earlier, “Hybrid, Single Page applications” are becoming more popular recently because they are solving the problems of business users. However, it brings some new problems for the developers.  

 

1. Customized code is required to merge content and presentation at the presentation layer making the code difficult to manage. 
2. As the content is managed separately from presentation, authoring becomes difficult. Custom authoring logic needs to be written which understand the source the content and update the content at the appropriate location. 
3. As the modern SPA frameworks like React and Angular work on a component approach, managing AEM components and their SPA counterparts can get messy. Just to remind you, we are in a hybrid approach, not a headless approach. Hence, the miscellaneous CMS concepts like components, templates still exist. One of the major advantages of hybrid approach is the separation of concerns of a CMS developer and that of a front-end developer. But this advantage is at risk when responsibilities of a CMS developer and that of a front-end developer overlap. 

These are the new set of problems which SPA editor framework is trying to address. 

How is trying to solve these problems? Does it just give just editing functionality for Single Page Applications? Was it not there in the first place? What's new here? 

As I wrote earlier, “SPA Editor” is a modest name. It’s more of a framework. The “Editor” was already existing in AEM. The editor, in-fact, is the same for both Single Page Application and Multi-page Application. Its main responsibility is to solve the problems listed above. 

1. SPA framework provides connector between presentation layer and content model 
2. It takes care of authoring by updating the content at appropriate path 
3. It provides JavaScript objects to map SPA components to their AEM counterparts. 

As mentioned earlier, please note that, hosting presentation logic inside AEM will not make the system any less hybrid. It can also be hosted outside AEM. 

 

Should I use it in my application? If yes, how? 

If you have a hybrid, single page application then surely, yes. You should also consider SPA Editor, if you are re-engineering your application from other approach to a hybrid, single page application. 

In conclusion, SPA Editor attempts to bring manageability to your code and makes it more modular. Please feel free to leave comments. 

References: 

https://dotcms.com/blog/post/headless-cms-vs-hybrid-cms-how-dotcms-goes-beyond-headless 

https://www.coredna.com/blogs/hybrid-cms 

https://docs.adobe.com/content/help/en/experience-manager-learn/sites/spa-editor/spa-editor-helloworld-tutorial-use.html