This is the 7th part of a series of blog posts about Shrine. In this part we will dive deeper into Shrine's eager processing feature, showing some interesting use cases that are possible thanks to its advanced API.

I’ve just released version 3.0 of Shrine, a gem for handling file attachments in Ruby applications. It’s been months of hard work, but I feel it’s finally ready.

The last couple of months I’ve been working hard to prepare for Shrine 3.0, which I expect will be released by the end of October. A lot of work has gone into it, including some big but much needed rewrites. I feel the API has stabilized now, so I thought it would be a good time to share with your some of the new features and improvements that will be coming to 3.0.

The ImageProcessing gem has just reached version 1.0, and I thought this would be a good opportunity to write an article about it. For those who don’t know, ImageProcessing is a wrapper gem that provides common image processing functionality needed when accepting image uploads from users (most notably resizing images).

This is the 6th part of a series of blog posts about Shrine. In this part we'll show how to do direct uploads to S3 or your app on the client side, as well as how to handle large uploads.

This is the 5th part of a series of blog posts about Shrine. In this part I talk about how Shrine extracts and stores file metadata.

This is the 4th part of a series of blog posts about Shrine. In this part I talk about doing file processing with Shrine, both on upload and on-the-fly.

This is the 3rd part of a series of blog posts about Shrine. In this part I talk about Shrine's high-level interface for attaching uploaded files to model instances.

This is the 2nd part of a series of blog posts about Shrine. In this part I talk about the foundation that Shrine is built upon – uploaders.

This is the 1st part of a series of blog posts about Shrine. In this part I talk about the motivation behind creating Shrine, by going over the limitations of existing file attachment libraries.

I recently released tus-ruby-server, a Ruby server implementation for tus, an open protocol for resumable file uploads built on HTTP.

Before talking about the implementation, I first want to explain where and why I needed partial downloads.

When I’m building web applications, a requirement that almost always comes up is that the app needs to accept file uploads. It can be an app with users that have profile images, posts that have cover photos and some additional documents attached, or whole galleries where people can upload many photos or videos.

When working on the Shrine library for handling file uploads, in multiple places I needed to be able to download a file from URL. If you know the Ruby standard library well, the solution might be obvious to you: open-uri.

Shrine is a full-featured library for handling file uploads in Ruby applications. Main advantages of Shrine are good design, loads of flexibility for achieving maximum performance and best user experience for any use case, and advanced features like backgrounding, direct uploads, logging and more.

Accepting file uploads in web applications is very delicate, because all actions for dealing with attachments are slow:

I’m really excited about this. I’ve just released Shrine, a new solution for handling file uploads in Ruby applications. It was heavily inspired by Refile, most notably its idea of backends. However, unlike Refile, it is designed primarily for upfront processing (as opposed to on-the-fly). It’s also inspired by CarrierWave’s idea of uploaders.