Another day, another monolith Ruby gem to reach deep into the bowels of your app config, models, views, controllers and make you manage uploading of file, storage of files, processing of files together with the rest of your business logic, only with the promise of loads and loads of syntax-sugar and enough config option to hang yourself with.

paperclip, carrierwave, dragonfly, refile, shrine…

The libraries may have high code quality, full coverage specs, flexible, comprehensive, easy, but it is bad architecture. I’ve covered most of them in this presentation and won’t repeat them here.

While the Ruby community wasn’t looking, the rest of the world has moved on to having standalone servers to manage & process their file uploads. Latest example: medium.com

When you adopt a server-client pattern (as oppose to syntax-sugar-into-my-monolith-rails-app pattern) you’ll discover can optimize, manage, scale independently, extend and improve using standard protocols; a whole new world of possibilities.

What? This rack+imagemagick server not working out for you? Swap in your own clustered-faster-attache.go server and your Rails app chugs along oblivious to the change.

What? Don’t like reactjs in the attache client gem? Introduce your own no-framework-js-attache gem and your attache server can remain oblivious to the upgrade.

What? Need to support that spanking new open protocol for resumable upload over unreliable network? Have option for Instagram-like processing? Well then add a middleware to your image server and both your server and Rails app can remain blissfully ignorant.

Architecture.

You already know it. That’s why the common pattern is to use a database, redis, nginx alongside your Rails app. Instead of just having syntax-sugar inside your Rails app to wrangle with b-trees.

Or maybe this will work better: microservices!