In my previous post Creating a Scalable Application Ecosystem, I described how to create an ecosystem of applications, libraries, and services rather than isolated applications. With this paradigm, you should end up with smaller, more manageable projects, but how do you manage all of these separate codebases?
The AEM Dispatcher is not just a caching engine and load balancer, is the first line of defense for your AEM application. That's why it's so important to ensure your Dispatcher is configured to be secure.
In many applications, although the application itself has an MVC structure, the application is built as a monolith. Services, libraries, and the application code are all intermingled, making the process of extending or creating a similar application far more difficult than should be required.
The dark corners of the internet and many an extranet are filled with enterprise applications collecting dust. These applications were once viewed as a potential solution to all of the businesses problems, but they have withered on the vine and are now an impediment to doing business every day.
The Apache Sling project just released the latest version of the Apache Sling Starter, version 11. This artifact is an aggregator of the modules making up Apache Sling and is used by many downstream applications as a basis for the "stable" version of the Apache Sling codebase.
This new Resource Filter API allows AEM / Sling developers to be significantly more succinct and readable and how they perform common repository traversals. It's not a pure replacement of JCR queries, but for simple content structures you can do a lot more with a lot less code.
Unfortunately, AEM did not provide a mechanism to interact with Markdown content, nor were any of the Java markdown libraries compatible with OSGi. Recently, I worked with the Flexmark team to produce an OSGi bundle version of the Flexmark markdown library.