5

The settings:

Blog with posts, buily with Laravel, where:

  • Every post can have max of 1 image (nullable).
  • Max posts in the blog is 1000. Let's assume there are 1000 posts for the discussion.
  • Every post has a comment section. Where registered users can comment and include an image in their comment. Lets assume every post has 2 images in the comments.

So in total it counts to 3000 images* that need to be stored (and resized I guess), presented, and etc.

This is the ideal amount in the long range, I'm not looking for a "scaleable" solution, since there is not going to be a crazy exponential growth.

*In reality for the time being it is less, and I assume that for these amounts of media files it doesn't really matter if its 1000/1500/2000 or 3000.. Correct me if that's wrong.

Few extra things to note:

  • I'm hosting it in shared hosting (I can store up to 300k files).
  • I want it to be secured, so no malicious file is uploaded in the cover of an image file.
  • I'm looking for a budget solution (so if s3 will start charging hard after 12 months it makes it not relevant), preferably free (.

So the dilemma is between storing all images locally in Storage folder (manipulating images with some Laravel package). Other possibility is cloudinary, which I don't know much about, just that it enables to store/manipulate/backup/use their api to present the images I stored there.

If I choose to do it locally - is it safe to store a user uploaded image locally? how do I make sure it's not malware in disguise of an image file?

With this amount of images/content can it cause performance issues in the shared hosting when storing locally?

What would be the advantages of using cloudinary for me?

Thanks.

nscode
  • 147
  • 1
  • 9
  • I would suggest going for a solution that you can change quite easily if you want/need to. If you have the space on your server and your traffic isn't going to be that high then I would say keep it local for now (unless there is a specific reason not to). Have a look at https://docs.spatie.be/laravel-medialibrary/v7/introduction/ and https://github.com/spatie/laravel-medialibrary/issues/1185 – Rwd Jan 19 '20 at 13:13
  • Thanks for the reply. Is this package basically an api for dealing with images? what is the difference between this and Intervention package? Also, would a few thousands of users a month is considered low or high traffic? – nscode Jan 19 '20 at 13:23
  • I would say that's quite low traffic. Intervention image is a package that is for manipulating images, media-library does this too but also provides a way to handle the storage and different manipulations of images. It's only a suggestion though, it might be that it doesn't suit your needs but it might give you a starting point if nothing else. – Rwd Jan 19 '20 at 13:31

1 Answers1

6

Cloudinary can actually help a lot in this case. Instead of storing the resources locally and writing something up to manipulate them, you could integrate Cloudinary in the project.

This would free up server space. Storing images locally may or may not impact performance, depending on the architecture, but freeing server resources is always a good practice.

Also, manipulation and delivery of images could be done on the fly when first requested (or eagerly before they are requested if you want to) by a simple API call. So you don't need to make up something new, but leverage already existing API.

Cloudinary also has a fully-featured free tier that you could use. If you don't expect exponential growth at the moment, that tier would be more than enough for the project

Full disclosure: I'm currently working at Cloudinary, (but the above still holds :) ).

Ido Bar Noam
  • 102
  • 4
  • Thx for the answer. Can you provide an example breakdown on how my use-case fits the free tier of cloudinary? assuming max of 3000 stored images and a few hundred users each day visiting the site and viewing different posts/comments that have images. – nscode Jan 19 '20 at 13:41
  • 3
    The free tier has 25 credits. 1 credit equals 1000 transformations or 1GB of managed storage or 1GB of monthly viewing bandwidth. Uploading 3k images and performing one transformation on each would be counted as 6 credits (uploading an image is considered a transformation plus 3k transformations on each of the uploaded images). Assuming each image weighs 1MB (high estimation) would mean 3GB of storage or another 3 credits This leaves 16 (25-9=16) GB of bandwidth for delivery per 30 days, which I assume a few hundreds of viewers a day won't consume, but that varies with traffic – Ido Bar Noam Jan 19 '20 at 14:21
  • Once I'm done uploading all of the 3k images/transformations, means that for the next month I will have again 25 credits which translates to 25GB available of bandwidth for my users to view/interact? Another question - is the CDN automatic or I need to integrate it? – nscode Jan 19 '20 at 14:35
  • 2
    Bandwidth and transformations are counted in a 30-day rolling window. So yes, assuming there won't be any more uploads or transformations after the initial uploads, after 30 days you would be able to use all of the 25 credits towards bandwidth The CDN is out of the box. Every resource that is delivered using Cludinary is delivered using a CDN. – Ido Bar Noam Jan 19 '20 at 15:42