Structural Static Assets in AEM as Client Library Resources

As developers, when we are building components or view logic, in typical scenarios require assets like background image patterns, icons, logos, typography, etc.. These assets are considered structural assets. Structural assets are assets that support CSS styles or JavaScript view logic; which are also static assets.

Structural assets should be stored and managed within the client library’s resources folder by the code package, and not in AEM Digital Assets Manager (DAM) “as content”. The AEM DAM is a very flexible AEM product where it allows users & groups to freely manage (based on ACL permissions) assets to make available for the public. Sometimes developers may find the ease of storing structural assets in the DAM (with the help of content authors), so they can quickly make the structural asset publically available for consumption. But, in fact, this is the wrong pattern to follow.

The reason why structural assets should not be stored “as content” and managed as DAM assets because:

• It would be surfaced to AEM content authors (the customers) during image selection when they are editing an AEM page that requires an AEM DAM asset; they can be confused, and they can potentially select on the structural asset (because it’s available for selection).
• It opens opportunities for interruption of our CSS styles or JavaScript view logic; where authors can actually delete/update a structural asset, and the website may look like it's broken.
• It would kickstart workflows; creating thumbnails, preview renditions, meta-data extractions, and other workflow processes… These are unnecessary asset processing… we do not want any thumbnails or renditions for the structural asset.
• Code like CSS styles or JavaScript logic referenced assets “as content” is not ideal, as DAM assets are maintained by authors, and can be unpredictability changed at any time.

Conclusion

• Structural assets should be stored and managed within the client library’s resources folder by the code package. It allows developers to have full control of which structural asset gets added, updated, or removed. 
• AEM authors have 0% chance of breaking accidentally removing one of these assets vs if structural content is stored “as content”, where assets can be managed and consumed in an unpredictable way.