The examples in these tutorials explained some basic concepts for building custom content apps. However, the subapps in the
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
, you can do caching on the container. If there are more containers, such as in the
example, it makes sense to cache the data on the service layer, for instance in
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-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") FlickrServiceImplyet 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.