Out of the box, Drupal is pretty good at handling files. It has support for subdirectories, and a wide range of tokens which gives you a flexible, easy-to-set-up system for organizing files uploaded by your users. Sometimes though, pretty good isn’t good enough, and we need something more. That’s why Drupal is built the way it is—modular and extensible. The module we need in this case is Storage API.
What is the Storage API?
The Storage API module extends Drupal’s standard file system handling. Instead of delivering files directly from your server, you can serve them from a variety of other locations, including Amazon S3. The capability to use S3 is built into the module by default, but it’s designed to be extensible so that it can work with other systems as well, if you’re willing to put in the legwork to get it there.
Using the Storage API has a number of benefits, one of the most important being that it’s simple to install and get it running. While it does require some basic knowledge of how Drupal handles files and field settings, no programming is required—unless you want to use a storage system where support isn’t provided out of the box, such as other online file storage systems (e.g., Windows Azure or Google Cloud Storage).
Some of the other benefits provided by built-in Amazon S3 capabilities include redundancy and load distribution. Amazon S3 stores files on servers distributed around the world. These copies can act as backups of any files you choose to store on their servers, however, the primary purpose of the Amazon S3 service is to distribute the load and get data to the user faster.
Rather than every site visitor bombarding your server with requests for every image file, the Storage API tells the visitor’s browser to get the images from S3 instead, lightening the workload on your server and freeing it to concentrate on actually running the site.
Sometimes Storage API doesn’t play well with other modules. While working with this module I had some issues with the popular Media module’s Library functionality. However, your mileage may vary, especially between versions, and there might be other compatibility issues out there as well—something you should be aware of with any contributed module.
Caveats to the Storage API
There are two important caveats to the Storage API. The first is that it will only send your files to other storage locations, such as Amazon S3, when cron runs. If you’re not familiar with cron, Wikipedia has a good overview, but a simplified explanation is that a cron job is a regularly scheduled task of some kind. In Drupal’s case, this mean a multitude of things, such as indexing your site’s content for search, archiving old content, or in the case of Storage API, copying your files to other storage locations. So, until your files have been copied over, Drupal will continue to deliver them from your server, thus reducing the benefits described above. However, this isn’t all gloom and doom, it checks on a per file basis, so just because your most recent files haven’t been copied to Amazon S3, that doesn’t mean that all of your files will be delivered from your server—only what has yet to be transferred.
The other caveat is fairly minor. When you enable Storage API, in order for it to work with and show up in the settings for the core image and file fields, you have to enable the Core Bridge module as well. This is a minor stumbling block, but one worth noting. Core Bridge is included with Storage API, so there isn’t any additional download required.
Storage API is a great module with a lot of good features. It’s easy to use and offers great benefits. If your site is having performance problems, Storage API isn’t the solution to all of your problems, but it can be a simple and effective way to help lighten the workload.