Production considerations

The examples in these tutorials explained some basic concepts for building custom content apps. However, the subapps in the flickr-simple-browser and flickr-browser modules lack some things you should take care of when implementing content apps to use in production systems where performance is critical.

Caching the data from the data source

Depending on the data source, you may want to cache data within the content app. In a subapp that has one common Container, such as in the flickr-simple-browser , you can do caching on the container. If there are more containers, such as in the flickr-browser example, it makes sense to cache the data on the service layer, for instance in FlickrService.

Lazy loading

If the data source potentially feeds your container with a lot of items, lazy loading starts to make sense. The Flickr account we use in the examples only has six photos. When using an account with ~1000 photos, the tree view of the flickr-browser module which is lazy loading performs well. But all other views are very slow, especially the thumbnail view of the flickr-simple-browser module.

Flickr-specific things to improve

For flexible production use, consider also implementing the following enhancements:

• Allow switching between different Flickr accounts. This way users can access more photos.
• $webResourceManager.requireResource("info.magnolia.sys.confluence.artifact-info-plugin:javadoc-resource-macro-resources") FlickrServiceImpl
   yet cannot handle flickr calls which require authentication.
• Instead of using the 3rd party library Flickr4Java implement some Java REST clients by using REST client module to consume data from flickr API.