A not politically correct assertion of my feelings towards a piece of software:
Note: Repetition builds cynicism, asset_sync
isn't bad, but when an asset problem cannot be solved via support it gets escalated to me. Often times someone using asset_sync
the problem is due to their use of the library and not from Heroku.
The asset sync gem uploads your assets (images, css, javascript) to S3. From there you can either point browsers to the copy on S3 or use a CDN + the S3 bucket. It's a good idea, and solved a problem at one time.
It is no longer needed and you should now use https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn instead. So rather than copying your assets over to S3 after they are precompiled the CDN grabs them from your website instead. Here's some reasons why it's better.
I like Ruby, and I like Rails. The concept of keeping your code DRY is more than good practice it allows you to have single authoritive places of information. If you need to change that information you change it in one place and that's it. With asset_sync
we're saying that although our "cannonical" copy of assets is in our source control, we're now relying on a 3rd party store of assets. What happens if someone has a failed deploy after assets get synced, what if someone modifies a file in the S3 bucket? Instead of fixing one copy of assets now you must fix two.
If I'm debugging on my app inside of a dyno heroku run bash
and I run rake assets:precompile
this doesn't just modify my local copy, it actually modifies the copy on S3 as well. This goes back to cannonical stores, it can be bad. All your assets are screwed up and you don't know why. The sync part of asset_sync can also fail if S3 is down, or there's a glitch in the network. What if you only write part of a file, or only half of your assets are synced. These things happen
Now that you can have a CDN dynamically grab assets from your website there is no reason to add an extra step into the process. You 100% should be using a CDN as Ruby is horrible for serving assets, and S3 is only slightly better. If I asked you to move a bag of cement from a car to a construction site, you probably wouldn't feel very much like carying it to virgina first. This is essentially what you're doing when you're using asset_sync. It's not a bad step, but it's not a necessarry step either.
Using asset sync can cause failures, is difficult to debug, un-needed, and adds extra complexity. Don't use it. Instead use https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn
I appreciate the authors of the software and everything asset_sync
has allowed developers to do in the past. Now it's not needed so please don't use it.
ktksbye
Comments on gists don't send notifications. You're basically shouting into the ether :(
asset_sync may not be the strategy for Heroku. However, it is useful in some deployment configurations. For instance, we're using AWS OpsWorks.
With OpsWorks, when you deploy, the servers don't restart at the same time. This meant we sometimes had Server A running new code, but Server B running the old code. When Server A received a request, it responded with a reference to the new asset. This asset would be fetched via Cloudfront, which might then fetch it from Server B. As the deploy hadn't completed on Server B yet, it would respond with a 404. asset_sync solved this problem for us.
With our strategy, the assets get built and pushed to S3 via our CI. It's only possible for us to deploy after the CI has passed (including this upload step), so we've never had a problem with assets being half uploaded. We're also using the asset hash feature of Rails, so we can have multiple versions of the same assets in the same s3 bucket. One side benefit of this strategy is that it shortens deploy times, as we don't need to run the precompile rake task on deploy.
I understand that your article was written from the perspective of Heroku support. I just wanted to provide a counter example where the asset_sync gem is still useful.