Future proof your applications with API Regions
Extensible platforms like Sling and AEM give users a lot of power as they can add their own code to the platform. Keeping these platform stable and predictable while at the same time allowing developers to use the third-party libraries they like, however, can present a challenge. For example, if the Sling platform happens to use some common library for its implementation this should not stop users from using their own version of that library. Similarly if the platform internally uses a library it should not automatically be available to users, as the internal library might change over time and we don't want the user's code to break.
In this talk we will introduce you to a novel approach to the problem called API Regions and how they can be used to solve some of these issues. We will show you how API Regions work in combination with the Sling Feature Model. Specifically, how they are declaratively described inside features, can then be checked using Feature Model Analysers, and ultimately, be enforced at runtime through standard OSGi mechanisms. Finally, we'll end the talk with a demo where you can see it all in action and we will show you how API Regions allow you to keep the platform clean, while still giving you the possibility to use any library at the implementation level.