@Lupestro wrote:
I am trying to figure out how to use fastboot in our delivery environment. On our corporate servers, deployment consists of populating an IIS site with a packaged tree of files - think of it as a zip. The zip has a single build of all source, suitable for deployment in production if it passes all the stages of testing. The only thing that can differ among the deployment targets is a per-target tree of static configuration files, which must be delivered to the build with the checked-in code. After deployment, the website’s entire directory tree is effectively read-only.
For an ASP.NET MVC application using Ember-CLI, we do the ember build to the www subtree of the application. When you visit the application, the MVC controller reads the www/index.html into memory, tweaks in a containing a JSON of all of the settings supplied in the server configuration that the client will need (similar to what Ember CLI does with the environment.js), and streams the result to the HTTP response. A service in the app reads the meta from the document and serves its pieces to the rest of the application.
Enter ember-cli-fastboot. I will direct fastboot to use the www subtree of the web app as the “dist” area, of course. It seems perfectly natural for my MVC controller to grab the response from the fastboot URL rather than reading www/index.html as the basis for its HTTP response. So far so good.
However, I’m running my full app in fastboot, and it needs those server settings from my siteconfig service to populate links, etc. It can’t use document.querySelector() to pull the meta, because there is no document object from which to retrieve the data, and there is no meta there yet anyway. So it will need my siteconfig service’s init() to invoke the fastboot service to see if fastboot is running and get them some other way.
How? environment.js is buried in the minified js and is therefore unavailable to me the minute the build is completed.
Ideally, I’d like to supply the data dynamically from the web app whenever the web app starts up.
If I had to, I could supply a set of config file at build time, shadows of the data in the web.config files for each target. It’s more error-prone. The separate web.config files are already one of the hardest things for us to manage. They’re the only thing that can really mess up for the first time on a production migration.
What are my options here?
Posts: 1
Participants: 1