URL-Based Thumbnail Generation

I am currently have a ‘products’ table that has a “:has_many”
relationship with a ‘photos’ table.

I am uploading photos to accompany products. Right now, I upload the
photo, save the metadata to the ‘photos’ table and the image to the
filesystem. Then, I direct a url from within the products display
pages to point to a thumbnail generator. For example, /products,
would display all the products with the product’s associated images.
The images would be formed by <img src="/photos/thumbnailer/?
height=200&width=200 ?>. The ‘/thumbnailer’ action then generates,
saves (based on sizes), and displays the thumbnail of the uploaded
file. If another request comes in for the same page, the saved
thumbnails are displayed and the ‘/thumbnailer’ action does not
generate any new images. Thus, there is heavy overhead only on the
first request. I like this because if I ever wish to change the
layout of the site, all I have to do is change the url to meet the new
parameters.

However, I have seen that most of the plugins that help with file
uploads tend to generate thumbnails at the time of file uploads. For
example, maybe a ‘small’, ‘medium’, and ‘large’ thumbnail are
generated and served up throughout the site. However, this seems like
more of a hassle to update if the design requirements change.

Since I am a new programmer, I am sure there are good reasons why
others do it differently (like many of the plugins). Any thoughts?
What drawbacks am I missing with my method?

Thanks

Andrew

On Fri, Aug 21, 2009 at 6:20 AM, Andrew P.[email protected]
wrote:

height=200&width=200 ?>. The ‘/thumbnailer’ action then generates,
example, maybe a ‘small’, ‘medium’, and ‘large’ thumbnail are

Doing it your way would mean that you have to keep track of whether a
thumbnail has been generated or not (extra complexity)
You would also have to run your image request through the Rails stack
instead of just serving the image from the file system.

By processing the images at upload, you now have images that can be
quickly served from the file system without going through Rails for
checking first.

If you want to change the layout of your site, you can run a batch
process that re-processes all the images to the new dimensions. A
number of the plugins allow for reprocessing
Photo.find_in_batches.each do |batch|
batch.each do |photo|
photo.reprocess! #<- psuedo method
end
end

Andrew T.
http://ramblingsonrails.com

http://MyMvelope.com - The SIMPLE way to manage your savings

Andrew P. wrote:
However, this seems like

more of a hassle to update if the design requirements change.

Look at it this way:

Suppose you have the “next big thing” and everyone is flocking to your
site to see and read about it.

Do you want your response cycle dependent on a hunk of code checking
whether thumbnails of a set of product images exist for every request
that hits a URL (especially when your intent is to have those thumbnails
available for serving)? For 10 users? For 10,000 users? For X users?

Or do you want your application to generate those thumbnails once, when
the images are uploaded? Don’t defer work that must be done, that’s not
simplicity. Get it out of the way as soon as possible.

Anecdote: At work a year or so ago, I was asked to improve performance
for a web process. In a nutshell, I a) stopped ‘dynamically retrieving’
certain data (that wasn’t truly dynamic) and formatting the results for
the web on the fly, but formatted and stored it at schedule creation.
In one test case, we went from 7000 queries to under 300, and the
response time went from 28 seconds to 3.

Main lesson: make the real work happen outside your request-response
cycle

Thanks so much for the feedback. Very helpful. I will be switching
my ways…

Andrew