Very interesting presentation, really on a high level, I enjoyed reading it.
I noticed that many problems that you mention other uploading gems have are actually solved by Shrine:
- "Transformation juggling" -- Versions are processed at instance-level, so you don't need to remember a class-level DSL.
- "File path config" -- If you change the location where your files are stored, the existing files on old locations will still work normally
- "Form validation dance" -- Very simple with Shrine, you just add an "<attachment>" hidden field.
- "Schema pollution" -- Shrine stores uploaded files exactly in the way that you described, in a single column as JSON
The idea of an image server indeed looks very interesting, but I think you're forgetting that this solves only one part of file uploads (although I agree it's a big part, and imgix looks really sexy). If you're using an image server, you still need to do:
- Caching the file (this still needs a direct upload endpoint)
- File validations (most notably preventing big files)
- Storing the file to image server (this still needs a background job)
- Model attachment logic (all of the assignment/callback logic)
One problem that I always had with on-the-fly processing is, if you have a page with a lot of photos, and you want to change the URL so that they're processed differently, how will that page look when a first person visits it? I think it will be horrible, the user will have to wait for a really long time to actually see the images, which is not nice user experience.
Also, the "image server" strategy can be used only for images, so if you want to upload documents, audio or video, you still need do regular processing on the application side. What's nice about uploading gems is that they provide a general solution.
> One problem that I always had with on-the-fly processing is, if you have a page with a lot of photos, and you want to change the URL so that they're processed differently, how will that page look when a first person visits it? I think it will be horrible, the user will have to wait for a really long time to actually see the images, which is not nice user experience.
we can still "pregenerate" after the author uploads his images, the browser just have to make the requests (not necessarily visible) and the image servers can cache those generated images for a long long time. then when the "first other person" view the page, those images are as fast as anything.
storing the generated image or not is still an image server's decision. my own implementation chose not to store because i find those generated files more trouble to carry around.
again, these are things for different image servers to iron out and one-up each other with.
> Also, the "image server" strategy can be used only for images, so if you want to upload documents, audio or video, you'll need to use something else. What's nice about uploading gems is that they provide a general solution.
actually, there's nothing in an image server that makes it inherently image only. i'd say file servers provide as general a solution as those uploading gems
for example, attache server handles pdf uploads well and even renders the thumbnail when requested via <img src="">. the same applies for any other file types - the goal is actually to render thumbnails for everything, as per how your desktop renders the same files are thumbnails.
again, these are things for different image servers to one-up each other with.
The imgix sandbox is meant as a tool to experiment and try things out.
Behind the scenes it uses imgix's production infrastructure via the published API. We think it's really helpful to be able to quickly iterate over ideas, and we plan to use it ourselves within our API documentation.
Assuming you're not using ImageMagick, what are you using and what makes your solution superior?
Do you have any benchmarks comparing against ImageMagick/GraphicsMagick?
Most of our feature benefits are derived from being a "full-stack" imaging solution. Because we know a lot more about the request and the client, we're able to perform operations to deliver the best image possible. One of the ways we do this is our automatic content negotiation strategy, which will serve up WebP images for Chrome, JPEG XR for IE 10+, etc. These more modern file formats tend to be much smaller, with some of our customers seeing a 40% reduction in their CDN bills as a result.
We're also able to push all of the work to our GPUs on our servers without worrying about noisy neighbors. This means our mean render time is 80ms, with the 90th percentile being 150ms. We wrote about our solution of racking Mac Pros: http://photos.imgix.com/racking-mac-pros
Sure, you can configure your own ImageMagick setup to do all of this. As you build this out, whether as an internal or external service, the economic realities of running ImageMagick in a virtualized environment catch up with you. It’s difficult to do this affordably and in a set-it-and-forget-it manner.
When explaining the benefits of imgix, I'm often reminded of the old jwz quote, "Linux is only free if your time has no value." Having stood up a few ImageMagick instances at previous jobs, I was happy to see imgix come along. Fast-forward a few years, and now I work there :)
Of course I have :) I used to use a combination of Trailers, Flixster, IMDB, and Fandango for my movie needs. This is sort of an amalgamation of all that with my twist.
You can surf trailers right now - there's a whole trailers section. Notifications are coming in the next version - with the use cases you mentioned (when the movie is out in theaters or available on itunes etc)
great idea! but is it necessary ux to burden the human user to manually trigger unlock? form onfocus or page onload should be less intrusive and still serve the purpose
timeline: like! i wish more news sites presents history in a straightforward manner
colors: not so much; not meaning & some combi are hard to read; favicon/logo/color-scheme-based-on-logo will be more useful
http: if the form method is "GET", then I can easily share or bookmark for updates later
text: some body text will be nice
https://github.com/avh4/elm-upgrade/issues/44