Progressive Web Apps (PWAs) in AEM(Adobe Experience Manager)

 This post discusses enabling the PWA feature for AEM websites using AEM core components and page properties.

Progressive Web Apps (PWAs) are web apps that use service workers, manifests, and other web-platform features combined with progressive enhancement to give users an experience on par with native apps.

Progressive web apps (PWAs) enable immersive app-like experiences for AEM sites by storing them locally on a user's machine and accessible offline. A user could browse a site while on the go even if losing an internet connection. PWAs allow seamless experiences even if the network is lost or unstable. The user has a local copy of the site with PWA, giving an app-like experience even without an internet connection.

Key principles a web app should try to observe to be identified as a PWA

• Discoverable — can find the content through search engines.
• Installable, so it can be available on the device's home screen or app launcher.
• Linkable, so you can share it by sending a URL.
• Network independent, so it works offline or with a poor network connection.
• Progressively enhanced, it's still usable on a basic level on older browsers but fully functional on the latest ones.
• Re-engageable, so it can send notifications whenever there's new content available.
• Responsively designed, it's usable on any device with a screen and a browser — mobile phones, tablets, laptops, TVs, refrigerators, etc.
• Secure, so the connections between the user, the app, and your server are secured against any third parties trying to access sensitive data.

Benefits of PWA:

• Mobile First
• Behave Like Native Apps
• Quick and Easy To Install
• Sending Push Notifications and other hardware features
• Enhanced Performance
• No App Distribution Platforms(App Store) Required
• Operating Offline
• Platform and Device-Agnosticism
• Enhanced Security
• Increased conversion rates
• Improved user experience

The tools such as Lighthouse can measure the completeness of the web app as a PWA, e.g., the site not enabled with the PWA feature.

Technologies used:

PWA is not a single technology but uses next-generation application programming interfaces (APIs) to incorporate features typically associated with native apps. These features include the ability to work offline, support for directly accessing a device's storage and other hardware resources, and an interface resembling a native app rather than a website. e.g.

• Service Workers
• Web Manifests
• Notifications and Push
• HTTPS
• Cache Storage API
• Index DB API
• Fetch API

Most of these technologies are now supported on modern browsers but need to factor cross-browser and legacy browser supports while building the PWA's.

High-level steps to enable PWA:

• Create your application manifest — This file defines how a device should display a PWA to the end-user. The manifest file makes it possible to create installable PWAs and appear to the user as if they were native apps.
• Create Icons — The Icon displays an icon for the app when the user installs the app in their application drawer. A PNG or a JPG will work fine.
• Enable Service worker — Service workers are scripts that act as middlemen between the web browser and the network. By intercepting network requests, they can process them in ways a conventional web app cannot. The Service Workers help the PWAs provide access to native device interface and hardware features.
• Enable HTTPS — The HTTPS protocol provides a secure transport layer that encrypts traffic as it passes between the app and other network locations (localhost work for testing without enabling the HTTPS)

Installation/Add to Home Screen:

"Add to home screen" is a feature implemented by mobile browsers that take the information found in an app's web manifest and uses them to represent the app on the device's home screen with an icon and name. The app is installable(install prompts to display) only if the app meets all the below requirements

• Have a valid web app manifest
• Be served over HTTPS
• Have a valid service worker registered
• Be visited twice, with at least 5 minutes between visits

In addition to the browser-provided install experience, it's possible to provide your custom install flow directly within your app.

Splash Screens:

While the user opens your PWA on their home screen, the default behavior shows a white screen until the PWA is ready. The default behavior doesn't feel very nice; adding a custom splash screen makes your PWA feel like a native app.

Chrome for Android automatically shows your custom splash screen so long as you meet the following requirements in your web app manifest:

• The name property is set to the name of your PWA.
• The background_color property is set to a valid CSS color value.
• The icons array specifies an icon that is at least 512x512 px.
• The specified Icon exists and is a PNG.

On Android, this works ok; however, iOS does not support a similar method of automatically showing a splash screen. Instead, you need to provide splash screens tailored for each iOS device using the <link rel="apple-touch-startup-image" /> HTML meta tag(Currently no option to enable apple-touch-startup-image to provide splash screens tailored for each iOS device)

Let us quickly see how to enable PWA features for the AEM websites — I am using Local Cloud SDK and a sample project created through the latest arch type for demo.

Core component PWA support:

Core Components release 2.15.0 and later fully support the PWA features of AEM sites. Since AEMaaCS always includes the latest version of the Core Components, you can leverage PWA features out-of-the-box.

Refer to the following URL to set up the SSL certificate for testing — https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/security/use-the-ssl-wizard.html?lang=en

Open the page properties of your root page e.g./content/pwademo/us/en

Select Enable PWA on the Progressive Web App tab

Define the Start URL — the preferred URL that should be loaded when the user launches the web application

Select the Display Mode — The display mode changes how much of browser UI is shown to the user and can range from browser (shows the entire browser window) to fullscreen (when the app is full-screened).

• Standalone (Like a Native app) — The application will look and feel like a standalone application
• Browser (Like a web page in a full browser window) — The application opens in a conventional browser tab or new window, depending on the browser and platform.
• Minimal UI (Like a native app but with minimal navigation browser controls) — The application will look and feel like a standalone application. Still, it will have minimal UI elements for controlling navigation.
• Full Screen (Like a native app in full-screen mode) — Uses all the available display areas and won't' show the user agent chrome.

Select the Screen Orientation — defines the default orientation for all the website's top-level browsing contexts.

• Any — follow device orientation
• Portrait
• Landscape

Set the Theme Color — defines the default theme color for the application

Background Color — represents a placeholder background color for the application page to display before loading its stylesheet.

Specify the Icon — Icon for the app. Currently not able to provide multiple icons tailored for different devices.

Cahe Management — Select the caching strategy.

• Moderately (Stale while revalidate) — This strategy checks for the response in the Cache. If available, it is delivered, and revalidate the Cache. If it is not available, the service worker fetches the response from the network and caches it.
• Frequently (Network first, cache fallback) — This strategy will try to fetch the response from the network. If it succeeds, it will cache the response and return the response. If the network fails, it will fall back to the Cache and respond there.
• Rarely (Cache first, network fallback) — This strategy will look for the content in the Cache first and, if not available, it will fall back to the network to retrieve it; if it succeeds, it will cache and return the response.

Files to cache for offline use — File to be cached to make web app functional in offline mode.

Select the required client libraries for caching

Add the paths included for caching

Add the paths excluded from caching

Save the configurations; now the site is enabled for PWA

Lighthouse report shows the PWA is enabled and all the checks passed

Also, now the browser displayed the install option to install the app to the home screen.

Click on install open the app also adds a shortcut to the home screen; you should be able to uninstall if required.

Next time open the app from your home screen shortcut

The Cache will serve the app if your server is unavailable or there is no network connectivity from the client machine.

Reference the manifest and service worker path from the source view.

The manifest file, e.g., http://localhost:4502/content/pwademo/us/en/manifest.webmanifest

{
    "name": "en",
    "short_name": "en",
    "start_url": "http://localhost:4502/content/pwademo/us/en.html",
    "display": "standalone",
    "theme_color": "#01FF70",
    "background_color": "#AAAAAA",
    "orientation": "any",
    "icons": [
        {
            "src": "/content/dam/pwademo/icon.png",
            "type": "image/png",
            "sizes": "512x512",
            "purpose": "any maskable"
        }
    ]
}

You can also review the Manifest details through the Developer console.

Service worker, e.g., http://localhost:4502/pwademo.us.ensw.js

The Developer console helps you review the Service Worker details; the service-worker uses the Workbox library; Workbox is a collection of libraries and tools used for generating a service worker and precaching, routing, and runtime-caching.

Note: You can use chrome://serviceworker-internals/ URL to view all the current service workers.

Manifest/Service Worker path mapping — etc mapping

While configuring the PWA properties internally, AEM creates etc mapping for manifest and service worker paths.

The sling match is not working as expected for the manifest file; the sling match should be [^/]+/content/pwademo/us/en/manifest.webmanifest, update the mapping for testing, I feel better to enable the mapping from the dispatcher to support the site-specific manifest and service worker URL's

Please note the sling match value reverts to the original value on every change of PWA configurations from page properties.

The Cache storage can be reviewed through the Developer console and deleted if required.

The customized app install flow can be enabled using the required event handlers (enable through custom script file)— refer to https://web.dev/customize-install/ for more details.

You can enable notifications or push notifications based on your need; refer to the following URL for more details https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Re-engageable_Notifications_Push.

You can't customize the default PWA service worker enabled by the AEM to handle the push notification — the page properties can control the Service Worker properties; create a custom service worker to support push notifications and other hardware features.

The caching is essential to make the PWA app function optimally; enable the required cache headers for different file types through the dispatcher or directly from AEM. The Cache header for the manifest file and the service worker is already enabled; you can override if required through the dispatcher.

Also, configure the required Caching Strategy through the page properties configurations.

You should adjust your dispatcher rules to allow access for manifest and service worker files — refer to https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/sites/authoring/features/enable-pwa.html?lang=en for more details.

We will not be able to customize the service worker currently(you can control the Service Worker properties through page properties), sometimes the customization of the service worker may require handling additional scenarios e.g offline pages — display the cached version of the offline page while the user or the server is offline.

As we discussed earlier using PWA(Progressive Web App) offers several benefits; same time it has some restrictions

• No access to apps stores
• Not all Hardware functionalities of the device can be used e.g Bluetooth or NFC
• The PWA and its compatibility with (mobile) browsers and operating systems are still under development
• The performance of native apps is still much higher than that of a PWA
• Browser or OS support — some of the advanced APIs are still not supported by IOS/Safari and some of the other browsers and legacy versions.

The PWA app is simple to start with an easy to manage to compare to native apps; same time provides support across multiple devices and browsers. The PWA apps help to improve the conversion rate and user experience quickly. Still, the PWA won't completely eliminate the native apps, the PWA vs Native App(In some cases you may need both) approach should be defined by reviewing the pros and cons of each approach and the business requirements.

Headless vs. Hybrid — Choosing an Enterprise CMS System

Headless vs. Hybrid— this is one of the most critical questions raised when organizations identify a new Web Content Management platform for their organization. The answer to this question is not simple and based on the business needs and other factors like current platform, resource skill, etc. In this post, I am talking about choosing the enterprise CMS system Headless vs. Hybrid based on my understanding; the process will vary based on your needs and current state( Happy to receive feedback ).

Let us quickly see some of CMS architecture patterns.

Traditional(Coupled) CMS architecture:

A Traditional/Coupled CMS knits the front end and the back end layers into a single stack.

• also known as monolithic architecture
• the tight connection between the back end and the front end layers
• Managed through a single platform
• Back end + front end(in the same system)
• WYSIWYG editors and templates — content authors can quickly create the content/pages.
• Example — WordPress Traditional CMS

Typical Headless architecture:

A headless CMS is a back-end-only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.

• Offers the backend for content storage and management
• API First Development
• UI is separated(Independent of backend) needs to build the experience layer outside CMS.
• Content-as-a-service (CaaS) API — omnichannel content delivery to any platform/device, REST, and GraphQL API endpoints are supported.
• CMS has no predefined front end with standard templates for displaying data
• Backend + API
• Lack of WYSIWYG editors or templates/components for in-context page editing
• Example — Content Stack and Contentful

Hybrid Architecture:

A Hybrid CMS (or Hybrid Headless CMS) gives you the freedom and APIs of a headless CMS with the marketer-friendly functionality of a traditional platform.

• Combines the features of traditional and Headless CMS
• the backend is separated from the front end by an API
• either use out-of-the-box templates/components for delivering content to the web or transmit your data to other devices via an API
• Backend + API + frontend
• Not API First Development
• WYSIWYG editors or templates/components for Enhanced in-context page authoring
• Inbuilt UITraditional Websites) + External UI(Headless Websites/Apps)
• Example — Adobe Experience Manager(AEM) and dotCMS

Let us now see some high-level challenges and positives for headless and hybrid architecture.

Let us see some CMS-based scenarios and the architecture suited for that scenario.

Website Only — the organization requires only websites, a traditional or hybrid CMS might fulfill the need.

App-Only — the organization is focused on an app or IoT, with limited editorial requirements; a headless CMS or Hybrid CMS might fulfill the need.

Mixture — the organization requires rich web content, URL handling, extensive editorial requirements, and reuse across different channels; a hybrid CMS might be the solution.

Based on the above use cases, this makes sense for some of the organizations to have two different platforms to manage headful and headless use cases; this will introduce management overheads and increase the implementation/operational cost.

Let us now see some implementation architecture with the headless and hybrid model.

Business Unit Specific Headless Architecture:

In this model, the global team creates and manages the content while the experience layer is hosted and managed by the individual(BU) teams.
The benefits of this model are the content is reusable, as it is hosted through a global CMS platform, while the BU teams will have the required flexibility to manage and host their websites and apps (Experience Layer). This model enables the individual BU's to manage their changes separate from other BU teams or global teams.
My view is that this is a more suitable architecture for the headless CMS. The CMS team manages the content globally, but each BU is in charge of its experience layer — the only concern is that BUs rarely have their development resources and hosting platforms; setup intern increases the overall cost.

Global Headless Architecture:

In this architecture, globally manage content and the experience layer, but at the same time, individual apps can consume the data as required. The benefit here is the global platform manages both content and experiences, which will help to reduce the operational cost. But the concern here is building a global FE platform that supports all the websites/experience requirements and managing the platform.

Global Hybrid Architecture:

In this architecture, the content is managed through a global platform; also, most websites are hosted into the same Hybrid platform using the templates and components enabled by the platform. At the same time, the content can be consumed by other channels through the content as a Service API whenever required. The benefit of the architecture is the single global platform managing the content globally and most of the websites while allowing to consume the Content through APIs to support omnichannel requirements. Some constraints are platform impact due to global changes, content duplication, component duplication, etc. — a robust platform governance process is required to minimize the impacts. Another constraint is locked down with the single vendor, which may create issues if any plan to migrate to a different platform.

Let us quickly see some of the essential parameters to evaluate while identifying the new CMS platform.

Complete/Centralized Platform:

The "Complete/Centralized Platform" is more about platform vs. stack; most of the Hybrid platforms provides the end to end capability to manage the business needs on a single platform, the same time Headless CMS system enables the content management stack(some headless tools enables additional capabilities) but need other toolsets e.g. hosting platforms, maybe a caching layer, etc. to enable the complete platform.

Authoring capabilities:

Flexible authoring capabilities

• enables authors to manage content and pages with less developer dependency
• authors can do WYSIWIG in-context page/content editing
• Create structured data for omnichannel delivery, tagging, etc

The hybrid platform enables in-context page/content editing, but at the same time, Headless platforms focus more on content editing.

Reusable Templates and Components(Headful):

Reusable templates and components to support traditional website delivery, the author should quickly use the existing templates and components to build new pages without dev dependency. Most of the Hybrid platforms enable the reusable template/components for simplifying the website delivery; at the same time, Headless platforms focus more on backend content management and delivery.

Content as a Service API(Headless):

Support for omnichannel delivery, enable different delivery APIs, e.g., REST, GraphQL, quickly expose the omnichannel Content through APIs, API first delivery for omnichannel focused systems.

The CMS Hybrid system enables the APIs to deliver the content across multiple channels but may not follow the API first approach; at the same time, Headless systems allow API first delivery channels.

Extendable/Customizable:

The platform is extendable/customizable to meet the organization's business needs and integrations. Most of the Hybrid systems are more customizable from both Front End and Back End; at the same time, Front End is entirely customizable in Headless architecture but will be some restrictions on extending Back End content management.

Media Library/Digital Asset Management Requirements:

The capabilities to support Media Library/Digital asset management requirements may be internal to the platform or flexible to integrate with external systems, support easy management of all the required assets, e.g., images, pdfs, videos, etc.

Search Capabilities:

Flexible search capabilities to identify the pages, content, tags, assets, etc.; hybrid platform enables centralized search capability to identify all the artifacts from a single location. The Headless architecture uses multiple systems to help the end-to-end solution that centralizes search may be a constraint.

Advanced Workflows and approvals:

The workflow capabilities set up the required business process flow for content/page review and approval.

Link management:

Link management helps the content authoring team manage the page links easily and update the content reference upon move/delete operations. The hybrid system may easily control the page links, references, etc., but Headless perspective developer support is required for link management.

Preview/Publishing Capabilities:

The capabilities to preview the pages/content quickly before making the changes live to the end-users also flexibility on publishing options, e.g., scheduled publishing, review/approval, etc. The Hybrid platform allows the content authors to preview the pages(Content along with experiences) before making; the headless systems will have limited preview capabilities, but some headless systems have started adding preview capabilities.

Migration(Reusability):

The migration from the current CMS system is one of the critical factors while identifying a new CMS system while the organization is currently on a CMS system; identifying the closest system helps you migrate the current artifacts while supporting all the business needs and addressing the constraints on the existing platform. The number of sites/integrations enabled with the current system, and the volume of content that should be migrated should be factored in.

Scalability:

Scalability is another important factor; the platform should auto-scale based on the ongoing business needs.

Security:

Security is another crucial factor; the platform should be protected from all security issues — e.g., XSS, DOS, etc. The headless architecture by default enables security by separating the content from the presentation layer. Still, additional effort is required to ensure the presentation layer s protected. The Hybrid system consolidates the security into a single platform but may need a significant effort to ensure the platform is protected.

Accessibility/SEO Support:

Accessibility/SEO support is a hot topic nowadays to ensure the site is accessible for all and ranked on the search engines. The headless architecture will enable the required flexibility to the FE developer to handle the Accessibility/SEO requirements(some headless CMS enables authoring capability to manage the SEO configuration, but development effort is required to manage them). The hybrid architecture empowers the marketing team to manage the page SEO but may need a significant amount of effort to enable the necessary capabilities.

Resources/Skillsets:

The availability of the resources and the required skillsets
Supporting the new platform implementation is one of the significant factors — should consider the primary technology switches, e.g., switching from Java to PHP. It is also how quick and easy cross-training the current resources into the new platform.

Dev vs. Marketing:

The control between Dev and marketing teams, Marketing team quickly performing the content creation/updates, launching Campaign sites, landing pages, new websites with minimal or no support from the Dev team — Hybrid architecture makes more sense.
On the other hand, the Dev team controls the FE delivery same time the marketing team only manages the backend content; the marketing team is dependent on the Dev team to complete most of the activities apart from Content authoring.

Personalization:

The platform should either support the personalization use cases OOTB or integrate seamlessly with external personalization/CDP engines.

Support for Modern Front-End frameworks:

The support for the modern Front-End frameworks, e.g., React, Angular;
The headless architecture gives complete flexibility to the FE developer to choose the required modern FE technologies for the presentation layer.
Hybrid systems may have some restrictions on using the modern FE frameworks for traditional website delivery(Some of the Hybrid Platforms Support Morden FE frameworks).

Multi-Site Support:

How quickly the marketing team can launch a new country/language site; by reusing the existing website pages/content
Most of the Hybrid platform provides the Multi-Site Manager framework to support this use case; Headless CMS enables the capability to generate multi-site content but may need effort from the FE team to enable the experience layer.

Cost:

The cost is the important factor most of the time to decide the CMS platform for the organization — the tool cost, hosting, operational cost, resourcing cost, etc. The Hybrid platform upfront cost(tool cost) will be more; the headless CMS cost will be minimal compared to the Hybrid platform but need to factor in additional tool requirements like Hosting platform, CDN, etc. Sometimes identifying the resources to support Hybrid will be challenging. Headless architecture needs more FE resources to manage the complete platform and the ongoing business requirements. The operational cost may reduce overtime for the Hybrid platform if enabled correctly but may increase for the Headless platform.

Access Management:

Manage the access for the content/pages/assets; the system should support the required level of access management to support the organization's business workflow. In most cases, the access management capability of the Headless systems is limited.

Translation:

Translation capability is one of the factors to support multilingual websites; most of the Hybrid/Headless platforms support automated translation processes.

Integration with PIM/eCommerce Systems:

The capability to integrate with the PIM/eCommerce may be optional based on the business requirements. Some Headless platforms enable integration capabilities with e-commerce platforms, but the overall responsibility stays with the FE team to build the required PIM/eCommerce integrations. At the same time, most of the Hybrid platform enables the connectors to integrate with the PIM/eCommerce systems (Consolidate the experience under a single platform)— but may need to watch out, the integration may well work with the e-commerce system part of the same vendor landscape, not with external platforms(customization/additional implementation required to support the external platforms)

Connection with Marketing ecosystem:

Another significant factor to consider is how well the system integrates with the Marketing ecosystem to enable the end-to-end personalized user experience. Most of the Hybrid platforms well integrate with the marketing ecosystems — the constraint is that they may integrate well with the marketing ecosystem supported by the same vendor, not with external systems. On the other hand, developer effort is required to enable the necessary integrations with the marketing ecosystem.

Version Control:

The requirement to version control the content, pages, assets, etc.; store the required number of versions for future references and auditing also restore the versions whenever required. Headless CMS versions the content; the only difference is Hybrid platform can version the actual page rather than only the content.

Cloud-Native:

Another significant factor is hosting options, Cloud-hosted vs. Cloud Native(SAAS) vs. On-prem hosted. In most cases, the headless platforms are Cloud Native(SAAS); the Hybrid platforms give different options. Some of the significant factors that influence the hosting options

• the data security requirements of the organizations — some organizations may not want to host the data to the cloud platform
• the effort required to keep the platform up to date with the latest capabilities/changes and security enhancements should seamlessly upgrade with new capabilities/changes and security changes.

Enabling Rich User Experience:

Delivering a world-class user experience is one of the hottest topics discussed now; the user experience impacts the website's bounce rate. The headless platform gives total control to the FE developers to build rich users experiences, at the same time Hybrid platform may enable some restrictions to the FE resources to allow the required experiences(most of the Hybrid platforms started supporting modern technologies for FE delivery, but still you may see some limitations), should use the headless feature of the Hybrid platform to support rich user experience requirements.

Vendor Lock-in:

The Hybrid Architecture may lead to long-time vendor lock-in; migrating to a different platform will be more challenging in the future, but at the same time, the headless architecture enables some flexibility on this considering both Content Management and Experience Layers are separated.

Some of the factors to answer the "Headless vs. Hybrid" architecture question

• business needs
• organizations Enterprise/Marketing architecture landscape
• Current CMS and the challenges and restrictions with existing CMS
• availability of the required resources/skills
• marketing team requirements(Dev managed vs. Marketing team managed),
• user experience requirements
• Dev flexibility
• the CMS use case(Website only, App only, Mixture), etc.

In my perspective, headless architecture is more flexible and built on modern tech stacks, so consider headless architecture.

• If the Frontend team can support all the business scenarios and integrations without much impacting the current landscape,
• Enough FE resources to handle the migration from current CMS, ongoing operational support
• The marketing team is ready to adapt to the new content management model and ok to lose the website management control then Headless architecture more suites.

Hybrid architecture more suites

• When website delivery is an essential requirement at the same time, it should support the omnichannel use cases
• Centralized/Complete platform to manage the web content management requirements.
• The marketing team required more control
• the Development team wants the flexibility to define the experiences based on the business needs(Headful or Headless).

Note: "This post reflects my personal view, not my organization's view."