You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we are serving our assets directly from an Amazon S3 bucket, not through a CDN. We signed up for the Free Tier service on the 10th of April, 2016, and will start being charged one year after (i.e. soon!).
In addition to this, going forward, we need to prioritise serving images quickly, revealing select image URLs securely in an API (signed), as well as being able to manipulate images easily.
Cloudinary is "a cloud-based service that provides an end-to-end image management solution including uploads, storage, manipulations, optimizations and delivery." In short, it should make our lives easier, and the free package does the job for us + does NOT expire. Thus, we should move our image management implementation over to Cloudinary. And ideally (but not necessarily) do it before the 10th of April.
How
There are several, detailed resources stepping through how to integrate Cloudinary with Rails, including how to migrate existing images over from another source:
We may have to move over from using the current Paperclip gem to CarrierWave as this is more supported by Cloudinary. But if we want an intermediate step to migrating, there is a limited Paperclip-cloudinary gem we can look into using first.
Set up a DML cloudinary account and record any auth details in our secure passwords spreadsheet (ask the team to add your email if needed). NB: We currently do not enable S3 locally, which makes it hard to test in development mode before staging / production. We might want to change this, so in local development envs we have the same asset solution but pointing to another local Cloudinary instance. So we may need to set up 3 accounts, local / staging / production
Switch from Paperclip to Carrierwave as our image upload tool
Integrate Cloudinary with our solution following the steps in the docs linked above, moving away from using S3. Ensure local, staging and production envs use the appropriate cloudinary account.
Regression test all the things!
The text was updated successfully, but these errors were encountered:
That's great news @kevinpmcc! 👏 Feel free to push the branch up and open a pull request for 90% review even with specs pending. Never too early for feedback! Also feel free to push what you have to staging for some QA. If you merge into the staging branch it'll auto-deploy to drawmylife-staging.herokuapp.
Blocks: #159
What
Currently we are serving our assets directly from an Amazon S3 bucket, not through a CDN. We signed up for the Free Tier service on the 10th of April, 2016, and will start being charged one year after (i.e. soon!).
In addition to this, going forward, we need to prioritise serving images quickly, revealing select image URLs securely in an API (signed), as well as being able to manipulate images easily.
Cloudinary is "a cloud-based service that provides an end-to-end image management solution including uploads, storage, manipulations, optimizations and delivery." In short, it should make our lives easier, and the free package does the job for us + does NOT expire. Thus, we should move our image management implementation over to Cloudinary. And ideally (but not necessarily) do it before the 10th of April.
How
There are several, detailed resources stepping through how to integrate Cloudinary with Rails, including how to migrate existing images over from another source:
https://devcenter.heroku.com/articles/cloudinary#using-with-ruby-on-rails
http://cloudinary.com/documentation/rails_integration#getting_started_guide
We may have to move over from using the current Paperclip gem to CarrierWave as this is more supported by Cloudinary. But if we want an intermediate step to migrating, there is a limited Paperclip-cloudinary gem we can look into using first.
The text was updated successfully, but these errors were encountered: