Where should I put the images for the Java app?

Question

I write an industry-grade Java API that provides you a few 100s JPEG images. The total size will be 15 MB which is not much. I believe that hosting the Java app due to this size is not an issue.

I think should I put the images inside the Java app or put in the cloud and read from there. What will be a better decision?

Answer 1

Ideal solution would be to have some sort of storage space like Amazon S3 cloud storage.

Benefits: 1. Central storage space : if wish to scale your application, each deployment would not have it's own copy of these files, that ultimately would avoid synch up problem across various deployment nodes.

2. File additional/updation without app re-deployment : if you wish to change these files in near future, you don't have to re-build and deploy your application again on all the nodes/server, but rather just update your files in the cloud storage space. Thus also avoid app downtime.

So, you need to assess if you would need these benefits compared to the cost of having a storage space, and how likely is it that you would be scaling this app.

Answer 2

I may add or remove a few of them after months. But, generally, they don't change.

In fact I would distinguish two cases :

1) your application renders/displays a list of images hosted in a directory and the most recent version is the better for clients.
2) your application uses/relies on specific images in its code to render/manipulate it.

For the first case, I agree with the Ankur answer : use an external storage to decouple the application component and its images. It is the right solution.

For the second case, using an external storage or storing the images in the application are acceptable solutions. Each one has its advantages and its drawbacks.

External storage

Advantages :

• don't bloat the application and its deployment with large files
• don't require redeployments for no structural changes (images content modified).

Drawbacks :

• Images set versions management : both in the external storage, in the application configuration and in the application code.
• require to perform multiple configuration setups and redeployments for structural changes (new image files).

For example, in the dev branch/env you could use the image set v.2 while you would use the image set v.1 for all other branches/envs that reflects the actual production component.
You don't want to spread the the image set v.2 everywhere as this will break the applications deployed in other envs. As a consequence, you need :

• to create as many spaces as versions with different images you want to deploy
• to make your application configurable to use the right version
• for each env that needs to use the image set v.2, you should update the application to take into consideration the version 2 images set and redeploy the application

Images stored in the source code

Advantages :

• no images set versions management (the SCM does that for you)
• no configuration change about image set version to use for every redeployement (images come from the SCM)
• certitude of the content used at runtime and no risk of networking/access configuration issue/unavailability (images come from the SCM and are stored or extracted aside the deployed component)

Drawbacks :

• bloat the application and its deployment with large files
• require to perform redeployments for any image set version.

---

According to my experience, if you use tools to automate your app configuration/redeployment (such as Ansible) and that you perform regularly deployments, the images stored in the source code approach is interesting because that is simple and the second drawback is not : "require to perform redeployments for any image set version." because you already redeploy often and that the whole deployment chain is effective.
If you feel brittle, uncomfortable about redeployments, using an external storage is probably safer while new images will always force you to redeploy the application to have a code that uses that.