9

I develop on iOS, and I'm switching from a PHP backend to Ruby on Rails. The interchange format is JSON.

A quick Google search for 'save images in Rails' has nearly every result talking about saving image data as blobs to the database. I might be mistaken, but I'm under the impression that saving image data in a database is a huge waste of time and space (as opposed to saving a link to the file location ('/img/subcat/4656.png').

In PHP, it's pretty standard to receive the data, generate a filename, save that file to disk, and update the database with the image's location on disk. Is this the same for Ruby on Rails, or is there some built-in ActiveRecord image functionality I'm not aware of?

3
  • 1
    I've stumbled onto PaperClip, which seems to be pretty close to what I want. Would still appreciate advice from experienced Rails folk on how to deal with serving and receiving thousands of images at optimal speed.
    – user
    Commented Sep 28, 2013 at 19:53
  • 1
    You do know that the image will take just as much space on db or on disk, right? From gut feeling, I'd say Rails stores on the database because it doesn't rely on apache as much as PHP to handle caching. That might be completely wrong though. Commented Sep 28, 2013 at 21:16
  • 2
    Yeah, I don't think the image data will be manipulated by the storage location. Rails might be different, but some trustworthy SO members seem to lean towards file paths in the database. Plus, I think it's conventional knowledge that databases are difficult to scale- so storing tons of image data in the database surely won't make that any easier.
    – user
    Commented Sep 28, 2013 at 22:30

2 Answers 2

4

What I've done in the past is use PaperClip with Amazon S3 and CloudFront CDN for faster delivery. PaperClip supports S3 storage very nicely out of the box: see their documentation for S3 storage configuration options.

  1. Set up a CloudFront distribution to forward image requests to your S3 bucket and other requests for static assets to your Ruby on Rails application (alternatively, you can upload those to S3 as well, but that's outside the scope of this question).
  2. CNAME a domain you control (such as assets.example.com) to point to your CloudFront distribution.
  3. In the PaperClip configuration, set s3_host_alias: assets.example.com. This will cause generated URLs to saved image resources to use your CloudFront distribution host.
  4. In your Ruby on Rails configuration, you can then do config.action_controller.asset_host = http://assets.example.com. Ruby on Rails asset URLs will then also use your CloudFront distribution, for caching/faster delivery.

That's pretty sketchy, but it hopefully points you in the direction of some useful resources. Of course, that's just one solution, but it's one that has worked for me in a situation where I was dealing with hundreds of thousands of image attachments in the database.

(As a possible advanced step that may not be necessary or useful for your case, you can also set up multiple CNAMEs for your CloudFront distribution, such as assets0.example.com and assets1.example.com. Both paperclip s3_host_alias and action_controller.asset_host can then take lambdas that will allow you to deterministically (based on the asset) generate URLs that use different hosts, for better parallelization if you're downloading a bunch of them on the same page, as browsers will limit the maximum simultaneous connections to the same host.)

3

I've tried several gems, but now I'm using FineUploader together with PaperClip

FineUploader handles a lot of the GUI for you, for example upload progress, drag-and-drop and multiple file uploads, and so on. I'm using PaperClip because I want to store the images on my servers instead of on S3.

What we normally do is look for a stable out-of-the-box configurable solution instead of recreating stuff from scratch. With PaperClip I store the images and with a StateMachine I do conversions on the images and put them into a category based on filename. I had the same question you had, and this was my best working solution, that's why I share it.

2
  • 2
    This is just a recommendation for an external package to do the work; the OP was asking for what Ruby on Rails devs normally do to store images, not for a recommendation. While this might be an example of how one package does it, this doesn't really answer the question. Commented Nov 3, 2013 at 9:04
  • True. What we normally do is look for a stable out-of-the-box configurable solution instead of recreating stuff from scratch. With PaperClip I store the images and with a StateMachine I do conversions on the images and put them into a category based on filename. I had the same question the OP had, and this was my best working solution, that's why I share it.. Commented Nov 3, 2013 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.