Upload tips & tricks

Shardimage was developed with the aim of it being the most practical and advanced tool for image hosting and image management. You have multiple options for uploading images, each with their own advantages. This is a guide to all the methods at your disposal, hopefully making your choice easier.

Upload directly vs. remote

Direct upload

When you choose direct upload, the content of the image file is handled through an API request. This method limits the amount of data that can be sent simultaneously, so the process needs to have a larger amount of RAM at its disposal.

This is an ideal choice in scenarios where the content is generated on the device (generated or uploaded by a third party) where you wish to upload it.

Advantages

• most often times it is the simplest method
• there are no issues with access and / or privileges

Disadvantages

• requires more memory
• limited size attachment
• if the files are stored at a third party provider, you need to calculate storage, download time and data traffic into your time
• in case of an error, the complete incoming traffic has to be paid to Shardimage (e.g.: the public ID had already existed before)

Remote upload

In the case of remote upload, only the link to the data will be sent toward the server, and the content of the image will be downloaded by Shardimage from the specified location.

If you have a chance to do so, this is the most practical approach.

Advantages

• low memory requirements
• the data sent to the API is small, so there are no limitations to the size
• sending the files is done mostly and probably by a server or provider that were designed for this task (static file servers, cloud storage providers, etc.)
• files stored at third-party providers can be uploaded to Shardimage without having to download it first (Amazon S3, Google Cloud Storage, http/https, etc.)

Disadvantages

• access / permissions (e.g.: providers that cannot be accessed remotely, etc.)

Tags

If the image tags are chosen correctly, later it can simplify the process of searching and identifying an item.

The most practical method is to label the items when uploading it, e.g.:

• admin<id> - admin:12371, admin:john.smith@example.com
• user<id> - user:234839228323
• app<id> - app:uploader
• app<version> - app:1.1
• site<domain> - site:example.com
• etc.

If you, for example, need to delete a user on a website, the images that have been uploaded by them need separate processes for deleting all their images stored on Shardimage one by one (or by groups). However, if labels were applied at the time of the upload, you would only need to apply one API call per cloud to the delete by tag endpoint.

Public ID

Using public ID may seem straightforward, however, you can save yourself a lot of inconveniences if you use it with the following things in mind.

The system generated ID is convenient to use. If there is a blog with less content, there are no risks; however, if you are dealing with a system that serves and works with hundreds of millions of images, even a slight error can cause serious problems and additional costs.

Let’s take, as an example, an incorrectly created /developed process, where the processing of the replies for an upload contains an error. The best-case scenario is that it is a one-time attempt and it gets lost among the images. If, however, it attempts the same process periodically, the result might be the image having been uploaded 10.000 times before you realize that there is something wrong. Additionally, if the process failed to employ labels, it takes a considerable amount of time to scan the whole image inventory.

In order to avoid this scenario, using a public ID while uploading is advised. The previous case example will look like this.

• the image won’t get lost, because you know the ID
• it won’t be uploaded multiple times since the Shardimage system recognizes that it already exists.