In September 2018 I’ve attended adaptTo() the fifth times in a row 4th times. Unfortunately I missed adaptTo() 2017 but I visited the conf in 2018 again. This year the organizers made the decision to rent a bigger venue in Potsdam, Germany.

adaptTo() is a technical meetup aimed at developers using the Apache Sling, Jackrabbit/Oak and Felix stack. 2018 was the eighth edition. Sessions also covered commercial implementations such as Adobe Experience Manager, with a particular focus on how these products leverage the Sling stack.

adaptTo() 2018 had 25 talks plus lightning talks, a playground session, hands-on labs and about 270 participants.
The slides and source code (if applicable) can be downloaded from the adaptTo() web site: https://adapt.to/2018/en/schedule.html

Below are my take aways from the conference.

Best practices

• Integrating a modern frontend framework
  • This is one of the most important decisions/activities on AEM projects.
  • In the talk you can learn about how to choose a modern frontend for an AEM project.
  • They recommend the following setup
    • Use Webpack to manage the frontend build tasks
    • Store the frontend code in component folders
    • Traverse the component folders for finding, compiling the frontend sources
  • There is a maven frontend plugin “Maven-node-grunt-gulp-npm-node-plugin to end all maven-node-grunt-gulp-npm-plugins.”: https://github.com/eirslett/frontend-maven-plugin
  • Be careful with lazy loading (of below the fold content) from SEO perspective
    • Use server side rendering techniques
  • Here you can read a lot more about Robust Configurations for AEM
• SPAs
  • Adobe releases the SPA editor for AEM in these days.
  • It is based on the Sling model exporters (@Exporter annotation)
    • There will be a demo site: We.Retail Journal
  • Alternatives
    • Generic React helpers and components supporting AEM authoring.: https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/reference-materials/spa/spa-react-editable-components/index.html
    • React DOM Components: this is an alternative for those who cannot invest into the full SPA editor
• Migrating to Touch UI
  • My key take aways here:
    • Reuse the existing content data structure in JCR (e.g. ensure the touch UI multified uses the same persistence)
    • Ensure co-existence of classic + touch components and their clientlibs
    • Avoid coralui 2 components and deprecated coralui 3 components
    • Be aware of AEM’s sustainable upgrades approach, which raises a numer of constraints regarding what OOB functionality can or can’t be overlaid.
• Modern authentication in Sling with OpenID Connect and Keycloak
  • Keycloak
    • Free, backed by Redhat
    • Supportsseveral SSO protocols: OpenID Connect, SAML, CAS
  • The approach
    • Authentication: Servlet filter, authentication handler
    • Authorization: Keycloak access control
    • User provisioning: external identity data exchange solution is proposed, e.g. SCIM
• Integration of web apps into AEM sites
  • There was a great summary of the various approaches, highlighting the pros/cons. Look at the slides if you need to implement the same.
• Content invalidation
  • This presentation filled a gap. They covered the topic of content invalidation in a thorough but enjoyable session. We learnt about the caching layers, invalidation models.
  • A few key learnings
    • Never purge the entire cache. Invalidate as precisely as possible.
    • Plan invalidation at the beginning of the project. Don’t leave it to the end.
    • It is possible to setup script on the DSP that can perform extra work when DSP cache is cleared. E.g. invalidate related resources or clear CDN cache by the DSP script.
    • Use the power of the Surrogate-Key HTTP response header to invalidate all pages that e.g. use a certain layout. Not supported by Adobe DSP, but other caches (Fastly) support it.
• How to analyze and tune deployments & upgrades
  • In this presentation we got a great overview of the evolution of upgrades from Adobe managed services.
  • They’ve analysed many projects to come up with the best approach for sustainable upgrades.
  • If you have a huge (really huge!) repository and need to upgrade, look at their presentation.
• Cluster deployment using Docker
  • Many of us have already realized container based AEM deployments.
  • However in this presentation they came up with a new idea that solves the problem of the monolithic, shared repository, in order to make AEM a better fit to Docker based deployments.
  • The idea is to use the composite node store, and store the read-only parts in the docker image (/libs, /apps), while storing contents in the shared repository.
  • Those who are interested can sign up the AEM Docker beta program.

Tooling

• Sling developer tooling
  • The community recognized that the market share of IntelliJ IDEA is higher than that of Eclipse.
  • Refactoring of the Sling dev tools was initiated to support easy porting to other IDEs
  • IDE support
    • Eclipse
    • IntelliJ IDEA
    • Netbeans (PoC only)
    • + CLI (command line)
• Maven archetypes for AEM
  • There are 3 popular archetypes
    • The official one from the Adobe Marketing Cloud
    • wcm.io – This is the most feature rich archetype
      • Webpack support
      • wcm.io features (CONGA, AEM mocks)
      • Feature flags to control what is needed in the resulting project
    • Lazybones templates by Adobe consulting
      • A more interactive project creation tool that I would position between the above two
  • We also learnt about a configuration management archetype for setting up AEM infrastructure and application.
    • Ansible automation – used for cloud deployment provisioning
    • Terraform – for AWS resource generating
    • Can be used to create local environment with Vagrant
    • Sensitive data encrypted using Ansible Vault
    • CONGA is used instead of runmode specific configurations
• Gradle AEM plugin
  • An AEM plugin to build rapidly AEM applications using Gradle Build System Gradle Sling plugin – fork of the AEM plugin
• Felix search plugin
  • A useful Felix plugin that searches for classes in OSGi console, de-compiles into java code and makes the code download able
• System ready framework
  • This is an upcoming solution for checking if AEM system is ready. This is a typical issue for those who want to automate AEM deployments and need to know when the system has started, finished indexing, etc.
• Easy content upgrade with Groovy Console
  • Groovy Console is a great tool. But these people made it even greater by adding many new features
    • Automated script execution on deployment time
    • Consolidated history
    • Runmode support
    • More features on the UI (batch execution, etc.)
    • Health check
    • And many more…
• AEM sync tool
  • AEM sync tool is just a handy tool that pushes code changes to AEM instance(s) upon a file change.

Coming soon…

In my next post I’ll describe my take aways from the following topics:

Testing

• Toughday
• AET – website monitoring with automated exploratory
• Karate – HTTP API testing
• JUnit 5 and Sling/AEM Mocks

Trending topics, outlook to coming features

• Java9 and OSGi R7
• Event driven, serverless solutions with Openwhisk
• Blockchain
• Feature model
• Sling scripting reloaded