Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
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.
- 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.