This document discusses approaches to leveraging Adobe Experience Manager (AEM) within single page applications. It begins by defining single page applications and explaining why companies integrate them with AEM. It then covers various page patterns, site patterns, and authoring/development patterns for integrating AEM and SPAs. These patterns include different levels of AEM involvement from fully managing the experience to acting primarily as a headless content repository. The document aims to provide clarity on AEM's role in SPA-based architectures.

1. #evolverocks
APPROACHES TO LEVERAGING AEM
WITHIN A SINGLE PAGE APPLICATION
PAUL MCMAHON
08/31/2016

2. #evolverocks 2
Paul McMahon – Managing Director at Accenture Interactive
North American AEM Practice Lead and Global Lead AEM Architect
• 14 years experience with AEM/CQ product
• First AEM/CQ implementation in 2002 (included integration to Blue Martini for
eCommerce)
Agenda
• What is a Single Page Application and why would you integrated it with AEM
• Page Patterns
• Site Patterns
• Authoring and Development Patterns
INTRODUCTION
PAUL MCMAHON

3. #evolverocks 3
WHAT IS A SINGLE PAGE APPLICATION
AND WHY WOULD YOU INTEGRATE IT WITH AEM

4. #evolverocks 4
Single-Page Applications (SPAs) are
Web apps that load a single HTML page
and dynamically update that page as the
user interacts with the app.
SPAs use AJAX and HTML5 to create
fluid and responsive Web apps, without
constant page reloads.
All of the display & rendering work
happens on the client side (browser), in
JavaScript.
Browser Browser
WCMS WCMS Other
backend
Systems
SPA
HTML HTML HTML
Traditional Site SPA Site
WHAT IS A SPA

5. #evolverocks 5
Enterprises are evolving toward Client/API approaches rather than continuing
to invest in Traditional Web
• Baseline experience and performance expectations for end users is now mobile native
apps; these expectations cannot be supported by traditional Web architectures
• Don’t create new systems every time you need to upgrade; instead create modular
systems capable of evolving
• Deliver architecture and high quality experience quickly; application development
lifecycle should be months, not years
• Enable fewer developers, designers, and testers to deliver applications for multiple
channels despite budget realities
WHY SINGLE PAGE APPLICATIONS

6. #evolverocks 6
The Client/API architectures tend to view content management systems as simply another
data source and not part of UI layer
• Enterprises are moving forward with these architectures and expecting AEM to a part of
the architecture.
• This often leads to challenges during implementations because Experience Management
requirements tend to get missed because there is often a focus on site functionality as
opposed to authoring functionality
• Having a clear patterns for how AEM can interact with SPA can help to avoid missed
expectations during implementations
• Without a clear vision for AEM’s role in a SPA based architecture AEM will often times be
relegated to a headless content repository with no role in managing the experience.
WHY IS THIS IMPORTANT
FROM AND AEM PERSPECTIVE

7. #evolverocks 7
APPROACHES TO INTEGRATING AEM WITH
A SPA
BASED REAL WORLD EXPERIENCE

8. #evolverocks 8
PAGE PATTERNS
Single Page App
(SPA Wrapper)
AEM Server-Side
Page
AEM Wrapper
for SPA
A Single Page App screen with
components. Upon user
navigation, only the relevant
sections (components) of
content are modified.
A traditional AEM server-side
page with components. Upon
user navigation, the entire page
is refreshed.
An AEM server-side page with Angular
Single Page app content. Upon user
navigation within the SPA, only relevant
components are updated. Navigating
outside of the SPA will force a full page
refresh.

9. PAGE PATTERN COMPARISONS
Pattern
Technical
Implementation
Benefits Drawbacks When to Use
AEM
Server-
side Page
Standard AEM
Architecture
Full authorability and
flexibility of entire site on-
demand (w/o dev). Easy
creation of microsites.
Full page refresh on every
URL change. No benefits
from the Single Page App
architecture.
Marketing pages and
Microsites.
SPA
Wrapper
Single Page App
content served as
through API from AEM
Publish servers.
SPA architecture benefits
(full page refresh on URL
change not needed, dev
tools, etc). Ease of
environment setup and
deployment (both local and
server). Ability to export
functionality to mobile app.
Partial
authorability/flexibility.
URL/Routing functionality
changes require code
change and new build
For transactional /
data-driven
applications and the
SPA encompasses the
majority of application
functionality.
AEM
Wrapper
for SPA
AEM Publish server
hosts Single Page App
content
copied/deployed onto
static web folders in
App Server.
Benefits of server-side
pages plus benefits of SPA
wrapper
Complexity of build/
deployment. Complexity
of routing between SPA
and AEM pages.
When SPA
functionality is a
subset of the overall
site functionality, or a
SPA needs to be
turned on/off on
demand

10. #evolverocks 10
SITE PATTERNS
• Mixed Mode Site – Mixture standard
AEM and AEM Wrapper pages in a
single site
• Experience management manages
content, html page and html
fragments, and SPA provides
functionality
• Most of experience management
capabilities are preserved with some
customization needed
• Potentially marketer has the same
control over user experience and how
content is rendered as the traditional
server side rendering
Hybrid Forest of SPA
• Single Page Site: The entire site is a
single page following the AEM Wrapper
page pattern.
• Experience management manages
content and html fragments which can
be loaded into SPA
• Some of experience management
capabilities are preserved with some
customization needed
• Marketer has some control over user
experience and how content is rendered
Single Page AEM Wrapper
• Single Page Site: The entire site is a
single page following the SPA Wrapper
pattern
• Experience management manages
content and html fragments which can
be loaded into SPA
• Most of experience management values
are lost
• Marketer has the least control over user
experience and how content is rendered
Single Page SPA Wrapper

11. #evolverocks 11
HYBRID FOREST OF SPAS APPROACH
MAKE THE PURIST WINCE

12. #evolverocks 12
Runtime Architecture
• Standard AEM physical architecture
• Web server is configured to pass all non-
API requests to dispatcher.
• API Requests are proxied back to API (or
separate API host can be used
Page Patterns
• Pages can either be standard AEM server
side pages or and AEM wrapper for SPA
pages
• SPA code is deployed CRX and served
from CRX
RUNTIME ARCHITECTURE
Browser
Web Server
AEM Instance
Cache
AEM Dispatcher
Cache
Template/
component
Content/assets
Rendering Engine
Integration API
Layer
Content
Proxy
Data
JSON
Other Backend
Systems
Data
$XXX.XX
Content/View
1 2
3
5
4
8
view
view
Data
4
6 7

13. #evolverocks 13
PAGE LAYOUT AND AUTHORING
SPA Component
SPAComponent
AEM
Compon
ent
AEM Component
AEM Component
AEM
Compone
nt
SPA
Compone
nt
SPA Component
• Component Types
– SPA Component
• HTL outputs content & SPA code
• SPA code can be included at template layer as
needed.
– AEM Component
• Traditional AEM component
• Authoring Experience
• Similar to traditional authoring experiences -
templates can be locked down to create
functional SPA pages with more developer
control or they can follow par sys approach
• SPA code generally doesn’t execute in author
mode.

14. #evolverocks 14
SINGLE PAGE AEM WRAPPER
PURIST WINCE LESS

15. #evolverocks 15
Runtime Architecture
• Standard AEM physical architecture
• Web server is configured to pass all non-
API requests to dispatcher.
• API Requests are proxied back to API (or
separate API host can be used
Page Patterns
• Single AEM wrapper for SPA page
• The initial page loads and all navigation
or screen transitions happen client side –
no more full page reloads
• SPA code is deployed CRX and served
from CRX
RUNTIME ARCHITECTURE
Browser
Web Server
AEM Instance
Cache
AEM Dispatcher
Cache
Template/
component
Content/assets
Rendering Engine
Integration API
Layer
Content
Proxy
Data
JSON
Modular View
Other Backend
Systems
Angular App
ControllerView
Content/View Data
1 2
3
5
4
6
8
9
view
view
Content JSON
Modular View
Modular View
Angular App
Controller
view
Data $XXX.XX
7

16. #evolverocks 16
PAGE LAYOUT AND AUTHORING
SPA Component
SPAComponent
AEM
Compon
ent
AEM Component
AEM Component
AEM
Compone
nt
SPA
Compone
nt
SPA Component
• Authoring Experience
• Similar to Hybrid Forest of SPAs, except the
AEM page represent routes in the SPA instead
site page
• Because it is full SPA on some of the templates
authors give up control to developers. The
degree which this true depends on the developer
• Requires a mixture of routes defined in code
(meaning certain AEM page must exist and must
be of a particular template
• SPA code does not execute in Author mode

17. #evolverocks 17
SINGLE PAGE SPA WRAPPER
PURIST HAPPY

18. #evolverocks 18
Runtime Architecture
• Standard AEM physical architecture
• Web server is serve most calls from doc
root
• Specific URLs like /content are
configured to route to dispatcher
• Calls from the SPA to AEM for content
can be routed through the API layer or go
direct to dispatcher based on preference
Page Patterns
• Single SPA wrapper page
RUNTIME ARCHITECTURE
Browser
Web Server
AEM Instance(publish and author)
Cache
AEM Dispatcher
Cache
Template/
component*
Content/assets
Rendering Engine
Integration API
Layer
Content(headless)
Content Data
Proxy
Data
JSON
Data
JSON
Other Backend
Systems
Angular App
Angular App
ControllerView
12
53
4
6
8
9
7
Content JSON
ControllerView
Data $XX.XXX

19. #evolverocks 19
PAGE LAYOUT AND AUTHORING
• Authoring Experience
• Authors generally have little to no control over
layout
• Developers typically control which components
are on which screens.
• There are patterns to allow more control of
specific routes or screens, but those tend to be
the exception rather than rule.
• For most content AEM serves up either JSON
raw content to be consumed by SPA components
• In some cases AEM may render and HTML
fragment for inclusion by the SPA
SPAComponent
SPA Component
SPA
Component
SPA
Componen
t
AEM Component
AEM
Componen
t
AEM
Componen
t

20. #evolverocks 20
AUTHORING & DEVELOPMENT PATTERNS

21. #evolverocks 21
Server Side Page
• Standard AEM
Marketing Pages Wrapped by SPA
• Applies to either of wrapper patterns
• Everything between header and footer controlled by author – standard AEM authoring
tools enabled.
• Renders HTML fragment server side
• Dynamic route creation – authors can create new routes on demand for marketing pages
SPA Route as a AEM Page
• Relevant to the wrapper patterns
• Every developer defined SPA route also has an AEM page
• Depending on the route the level of control authors have may vary – there may be a well
defined content model supported by that route defined in the template, or sections of the
routes views may be designated for author control with HTML fragments rendered server
side
AUTHORING PATTERNS

22. #evolverocks 22
Content Fragments
• Reusable content fragments potentially referenced by multiple locations in a SPA
• Allows for either HTML fragment rendering or raw JSON content
• Requires the SPA developer know the URL of the fragment to be included, or some other
configuration mechanism to inform the SPA of the fragment URL
Simple Text Configuration
• Simple name-value pair text mapping
• Great for simple text content like field labels or descriptions
• Can be used in a variety of taxonomy patterns – on config page per route, or apply global
inheritance and override rules.
• Can be used to allow authors to point to images or content fragments
AUTHORING PATTERNS

23. #evolverocks 23
Authored SPA Components
• Allows authoring of a component the includes SPA functionality
• HTL prints out some combination of server side rendered content with embedded SPA
directives
• A mechanism must be designed trigger the SPA directives client side
• Most common in Hybrid Forest of SPAs, but can be applicable in other patterns
AUTHORING PATTERNS

24. #evolverocks 24
Authoring
• Preview – have to provide a punch out mechanism to allow full SPA preview
• May need a staging environment to do accurate preview
• SPA components may need switches – one version with a mockup of the component for
author mode and one version for publish mode
Development
• One set of developers can end up feeling like second class citizens without investment in
good process and tools
• These process and tools are not yet standardized so the must be built out for each
implementation
• Requires either T skilled developers for really good collaboration between SPA and AEM
developers
CHALLENGES

25. #evolverocks 25
ABOUT US
Mail
paul..m.mcmahon@Accenture.com
Twitter
https://twitter.com/Acc
entureSocial
Linkledin
https://www.linkedin.com/company/a
ccenture-interactive
Paul McMahon
Managing Director
Accenture Interactive
Contact Us
https://www.accenture.com
Phone
602.337.4608

26. #evolverocks
THANK YOU!