Using ember-cli-rails without the Rack middleware

[pwim]

This isn't so much an issue per se, but I'd like to introduce how I got ember-cli-rails working for us, as it might help someone else in a similar deployment situation.

Our deployment flow is the following:

1. Build the assets on our CI server
2. AssetSync puts the assets into a S3 bucket
3. Oops packages our Rails application, along with the assets, into a zip which is uploaded to S3
4. Our production servers download the packaged Rails application and run it

Out of the box, ember-cli-rails doesn't work with this deployment strategy because it relies on the CDN fetching assets from your Rails application (to go through the Rack middleware).

I've managed to hack together the following to get it to work by compiling the ember app into my assets directory:

# config/intializers/ember.rb
EmberCli.instance_variable_set(:@root, Rails.root.join("public/assets/ember-cli").tap(&:mkpath))
EmberCli.configure do |c|
   c.app :frontend, exclude_ember_deps: "jquery"
end

And then bypassing ember-cli-rails middleware:

# in the template
prepend = asset_url("/assets/ember-cli/apps/frontend/")
include_ember_script_tags(:ember, prepend: prepend)

include_ember_script_tags is already taking care of rebuilding the ember app in development and test, so I actually don't need to use mount_ember_app in my routes.

If this deployment strategy is something that ember-cli-rails would like to support, I'd be happy to make a PR that supports it in a cleaner fashion.

[seanpdoyle]

If this deployment strategy is something that ember-cli-rails would like to support, I'd be happy to make a PR that supports it in a cleaner fashion.

@pwim thanks for your interested in modifying ember-cli-rails!

Please do submit a pull request, as we'd love to see what code changes are necessary to support your particular use case.

Some things to note before starting:

• Your use case sounds like a great candidate for an external deployment strategy gem. It'll be a lot easier to discuss the technical details of extracting it to an external gem once we have a PR and code diff to discuss directly, but it's something to keep top of mind
• ember-cli-rails-deploy-redis was the first "third party" deployment strategy created to integrate with this project. You should check it out as inspiration for how a deployment strategy could be structured.

include_ember_script_tags is already taking care of rebuilding the ember app in development and test, so I actually don't need to use mount_ember_app in my routes.

• I think it's worth reiterating that include_ember_*_tags helpers are deprecated in favor of using mount_ember_app. They're implemented via a dependency on ember-cli-rails-assets, which will be removed in the not-so-distant future. If your deployment strategy is somewhat set in stone and not able to be reconsidered, it's probably worth depending on ember-cli-rails-assets directly, instead of relying on the helpers existing in ember-cli-rails-proper.

Please ping me on your PR -- I'm looking forward to seeing what we can change to support your use case.

[yemartin]

I have an issue where the root cause is related to this, but I don't think a third-party deployment gem as suggested by @seanpdoyle would work for it. So let me chime in here. The issue is:

Out of the box, ember-cli-rails breaks rolling deployments on the Engine Yard platform.

The issue happens as follows:

• On the rolling (no-downtime) deployment process on Engine Yard:
  • it uses a unique, shared tmp/ folder (for no downtime, stuff like pids, sessions, sockets need to be shared between deployments)
  • it builds the assets on the production servers as part of the deployment process.
  • it has various strategies to prevent breaking existing assets across deployments (like having private, per-deployment public/assets, then symlinking assets from the previous deployment into the new one)
• ember-cli-rails
  • builds its assets under tmp/ember-cli/apps/#{app_name}
  • has a middleware that serves assets from there
  • does a rm -rf tmp/ember-cli when building assets

So the issue is two-fold:

1) while ember-cli-rails integrates with the rake assets:precompile task, because it builds its assets under tmp/ember-cli instead of public/assets, it cannot leverage the Engine Yard assets deployment strategies (so even if the next issue didn't exist, we would see broken assets around the Unicorn workers restarts).

2) the major issue, and show stopper for us, is this: since tmp/ is shared, the rm -rf tmp/ember-cli that ember-cli-rails does before compiling means clobbering the production assets served by the currently running rack middleware, resulting in a long downtime (until the deployment process completes and Unicorn workers are restarted).

To solve these issues, I was researching how to configure the folder ember-cli-rails builds to, which happens to be exactly what the hack proposed by @pwim does.

Now while providing a clean and supported way to set the ember assets build folder would help a lot, I am wondering: would it make sense to change the default tmp/ember-cli to public/assets/ember-cli? Since the goal of ember-cli-rails is to integrate with the Rails workflow, it feels more natural to use public/assets anyway. Or is there any good reason not to do so?

[pedromtavares]

Thank you SO MUCH for this @pwim

I highly urge for the embler-cli-rails team to adopt this strategy as some sort of plugin and mention it on the wiki, because for those of us who don't use the exact same deploy strategy that the gem supports, it is a complete nightmare to get things to work -- only this solution got things properly working, which to me was a huge regression considering the previous versions that used the asset pipeline made it so much easier for custom deployment strategies to work.

[seanpdoyle]

I highly urge for the embler-cli-rails team to adopt this strategy

Every new addition to the codebase takes time to both implement and maintain. The deployment strategy described above is unlike the deployment processes that have influenced how this gem has been implemented.

Since my and other maintainers don't use that strategy, we won't be able to efficiently maintain it.

If deploying to Heroku (via the configuration described in the README) doesn't suit your needs, we recommend you consider deploying via ember-cli-deploy.

ember-cli-deploy has emerged as the community standard for deploying EmberCLI applications. There are numerous plugins that support various backends, including the Lightning Strategy, which ember-cli-rails can integrate with via the ember-cli-rails-deploy-redis gem.

The more recent changes to ember-cli-rails were made with ember-cli-deploy compliance in mind.

The biggest theme to those changes was shifting responsibility away from Rails and toward EmberCLI, relying on that community's tools and best practices instead trying to keep pace from a Rails-centic perspective.

Whether or not Heroku or the Lightning Strategy is right for you, I strongly encourage that you consider adopting an ember-cli-deploy based deployment process.

If you decide on an ember-cli-deploy plugin outside the Lightning Strategy, we'd love to see PRs against this gem for supporting those strategies!

[plapinhh]

Hi! The issues is closed, but nevertheless...

We have quite big Rails application with big EmberApp (still non-cli) which is but only a small part of frontend. Now we are on the move to Ember-Cli step by step and looking for minimal effort to do it and we have a problem with our setup like described above.

Reading the discussion I think the only ask is to add an option to configure the path where generated assets have to be stored in. I don't think you have to maintain or care about other deploy strategies. But as you can configure in Rails the most of stuff, so you can support an option to set the assets path.

The impossibility to change the tmp directory is just too inflexible, IMHO having said that tmp is not the best place to store anything.

The lines like EmberCli.instance_variable_set(:@root, Rails.root.join("public/assets/ember-cli").tap(&:mkpath)) may help for a while, but have a smell of monkey patching and don't give a warrant it works after next update.