Here's a list of Pros and Cons for each of the approaches.
Server-side uploads
Pros:
- You can have your own custom logic and validations in place before proceeding with the upload to Cloudinary
- You can easily apply many additional optmizations and transformations dynamically, without having to set multiple unsigned upload presets in advance, for each of the required scenarios
- It allows you to store the asset on your own bucket, if needed, before uploading it to Cloudinary.
Cons:
- Upload takes longer. The asset is uploaded twice. Once from the client's browser to your server and second time from your server to Cloudinary.
- Wasting server resources which you probably have to pay for your hosting service (i.e. AWS) - Computing, Bandwidth, Storage.
Client-side uploads
Pros:
- As you've mentioned, it is faster because once the client finished uploading the asset, the upload is completed, without the need for the second upload from your server to Cloudinary.
- Optional quick implementation with Cloudinary's Upload Widget
- Either you have one upload or one million uploads a day, this has no impact on your servers. You don't need to care about handling bottlenecks of upload queues, scaling up your servers and of course, again, you save the costs of this operations. On top of that, your clients' user exprienece and loading times aren't affected when simultanous uploads occur.
Cons:
- You must use upload presets for your uploads. You can't just simply add/modify Cloudinary's optimizations & transformations parameters in your client-side code, unless you sign your reuqest. Generating signatures should only be done on the server-side so that you won't expose your API Secret publicly. Therefore, this requires you to send each request's payload to your server to get back a signautre before actually sending the request. This results in every client-side upload to rely on your server after all, although not having to deal the actual upload which is more resource consuming.
You should also note, that if you also use the Admin or Search APIs, those should never be done from the client-side as these are administrative actions that require full credentials authentication. Therefore, if you do use it, you will inevitably need to have a server-side implementation for those.
To sum things up, there isn't one approach that is ultimately better than the other. It really depends on your use case, needs, and preferences.
