Since the beginning we added the possibility to upload a logo to visually identify you and your API. To add this simple feature, from a code point of view, we designed an interface defining basic operations on the uploaded images: load, save, move and delete.
The first implementation was simple and fast to deliver: an abstraction of the local filesystem.
This is fine during the development phase, on our laptops, but obviously, you can’t scale with this solution: every server would have, locally, his own copy of the files.
We haven’t changed a single line of code on our website, except for a configuration file (filemanager.properties). To achieve this goal (and to allow us to change again, in case) this is our design (that can be improved):
Singleton design pattern on FileManagerFactory, with a single static instance that creates an instance of FileManager based on the class name found in a text file (a Properties configuration file).
In this way when we create different Tomcat instances, each of them will have a static FileManagerFactory to access to the same storage.
This simple library fits in our project, in our needs, so it’s not the best fit in every case. But it can be useful for other fellow developer, so here it is: https://github.com/Mashape/file-manager
For example in other scenarios woule be better a dependency injection pattern instead of a singleton or maybe to avoid the fallback to the default filename ”filemanager.properties” when a getInstance() is called.
Just in case…fork it ^__^