How we handle your logos using S3 FileManager

Since the beginning, we added the capability to upload a logo to visually identify you and your API. In order to support this feature, we designed an interface defining basic operations on the uploaded images: load, save, move and delete.

The new S3 FileManager replaces Live server on laptop

Thankfully, our FileManager is no longer running like this
Image credit: https://flic.kr/p/4EsmJw

The first implementation was simple and fast to deliver: an abstraction of the local filesystem. This was fine during the development phase, on our laptops. However, it was not possible to scale with this solution as every server would have his own copy of the files locally.

Hence, I developed a new implementation, S3FileManager (based on the S3 library provided by http://www.jets3t.org), to store data directly on the awesome Amazon service that we are already using for our static web part (css/ images/ javascripts). We did not change a single line of code on our website, except for a configuration file (filemanager.properties). This is our design (which 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 the same storage.

While this simple library fits our needs for the project, it may not be the best fit in every case. In case you find it useful, check out the github repo here: https://github.com/Mashape/file-manager

One area of improvement would be using a dependency injection pattern instead of a singleton, or perhaps to avoid the fallback to the default filename  ”filemanager.properties” when a getInstance() is called.

If you like this, remember, to fork it!