An alternative to Active Storage: Shrine

Captain's log, stardate d257.y38/AB

Development Ruby Rails Ruby on Rails Gems Active Storage Shrine Rosetta
Oriol Collell Martín
Backend developer
An alternative to Active Storage: Shrine

We are using Shrine as an alternative to Active Storage for our own product, Rosetta. Here's why.

A few days ago, we announced that we're building our first product, Rosetta. You can read the blog post announcing it here: Venturing into Developing Our Own Product.

Rosetta will be our first excursion into developing a full product for ourselves, which can serve a big number of other companies, especially in the HR sector.

Even though we have also recently announced that we're offering Node.js and React services, we're developing Rosetta with Ruby as backend language.

Using Shrine as an alternative to Active Storage

Active Storage is widely used as the go-to solution to upload files to cloud storage services such as Amazon S3, Google Cloud Storage, or Microsoft Azure. Active Storage attaches said files to Active Record objects, and comes as a standard inside Rails since it was first introduced about a year ago.

We have since then adopted Active Storage in our projects by default, but the growing number of issues over time have become a concern. Mainly:

These issues have forced us to look for an alternative.

Enter Shrine.

Shrine is a viable alternative to Active Storage which provides an extensive toolkit for file attachments in Ruby applications. Lately, it's gotten a lot of attention, and its growing popularity is matched by some really nice advantages:

What's more, its integration with Rails is really straightforward and its interface is really easy to use and understand.

If you want to read further technical details about this, read the Shrine advantages documentation.

Some quick wins

As a result of using Shrine in our own project, we have found a viable alternative for projects where Active Storage just doesn't cut it. No more one-size-fits-all for the management of file attachments.

Further, I configured the AWS account used by Shrine to have strictly and solely the permissions it needs. To do that, instead of creating a user and just assigning the "S3FullAccess" policy, I have created a custom policy that only grants the S3 permissions needed and only to the development bucket.

We will need to create another one for production and staging. This has the added benefit that it's impossible to modify something in the production bucket by mistake by using the development keys, so it reduced the human error factor.

Not that this is something that can't be done with ActiveStorage. It's independent of the solution we used, but while I was at it, I took the opportunity to do this improvement in security.

I'm sure I'll find more advantages to using Shrine over Active Storage, but I will follow up with more information as soon as I find interesting stuff to share.

Stay tuned!

Share this post

Related Articles


How we upgraded an obsolete Ruby on Rails application with lots of legacy code (part 1)

This post is the first one of a series where we break down how to correctly upgrade a Ruby on Rails application.

Read full article
How I use Docker for Rails development: running services

How I use Docker for Rails development: running services

Project setup can be a very cumbersome process for developers. In this blog post, our developer Dani explains how he uses Docker to develop in Rails

Read full article

Speeding up views rendering in Rails 4

Here's some technical post for the Rails folks out there. If you're into performance optimisation, this is for you!

Read full article