Companies are putting more and more apps in the cloud because the cloud model keeps business agility during the app's lifetime; relevant benefits include high-performance access to data, data safety, and scalability.
Regarding multimedia storage (for videos, audios, or images), there are several compelling reasons to use external storage rather than storing data in the database, which are detailed below:
To ensure the scalability of a clustered application, the server file system cannot be used to store the multimedia, because it cannot be guaranteed that the same server will serve the client in the next HTTP request.
The traditional way of saving images is in the database. When requested, they are downloaded to the file system of the same server where the application runs (related to the Blob Local Storage and Temp media directory property properties). This is a drawback for applications that run on a cluster with no server affinity, where different nodes can serve the images regardless if the web session remains the same.
Data should be guarded against access by non-authorized users.
The disadvantage of saving multimedia files in the database is that when they are retrieved to display an image, for example, it is temporarily stored in the server's file system in a location accessible from the web app (the Temp Media Directory). In addition, the file that is automatically downloaded to the file system when an image is retrieved to be displayed can harm the application or the server's stability.
With external storage, you can prevent data from being dangerously exposed to unauthorized users and protect the server from malicious attacks.
Temporarily storing data in the server's file system implies an I/O penalty. This can be avoided by using the external storage mechanism.
When an external storage system is used, multimedia files aren't stored in the database and the storage file location URL is saved in the "_GXI" column of the table.
In other words, every insert or update from any source (they can be procedures, Business Component, or Transactions) automatically manages the data in the external storage. In addition, the external storage is automatically retrieved. The user doesn't need to program anything or change its logic.
For versions previous to GeneXus 15 upgrade 12, it is available for Image data type, Audio data type, and Video data type. Blobs are not included, and they are stored in the database as usual.
As since GeneXus 15 upgrade 12, the BlobFile data type supports the implementation also.
There are several external storage providers to choose from:
Amazon S3
IBM Cloud Object Storage
Windows Azure Storage
Google Cloud Storage
After having decided which is the most convenient provider for you, and setting all the necessary configurations in the cloud, you just need to configure the Storage Provider property or use the Storage Provider API in GeneXus.
This is valid for Web and mobile apps as well.
The CloudServices.config file includes the information for connecting to the external storage, so this file has to be taken to production. It's located in the WEB-INF folder for Java applications, and under the virtual directory for NET applications.
- When using external storage, data will always be automatically stored in an external manner as it is updated from the application. For this reason, you can start with data stored in the DB and end up with the data externally stored if it is updated using the application. The other way round, if you use external storage and change to database storage, you won't get any errors because the external storage remains accessible while the data isn't updated again. When the data is updated, it is stored in the database.
- When you delete a record, multimedia files aren't deleted from the external storage.
- If you change the bucket name or folder along the way when you retrieve the data the application won't throw any errors unless you remove the old bucket or folder. From then on, the application will store the files in the new bucket or folder.
- When using Amazon S3, the Bucket name must have "Public Access". This means that to access the file no authentication is performed; so, having the URL to it, it is accessible. If this solution is not suitable for you, we recommend using the Storage Provider API.
Storage Provider API
Required configuration for Amazon S3 bucket