Where do Fastboot initializers go?

rondale_sc · May 1, 2018, 7:32pm

Mostly documenting for future travelers:

I needed to run an initializer only in FastBoot land. Rather than guard for FastBoot I want to use a FB initializer.

In an addon you can do so by adding your initializer (in my case an instance-initializer) to:

<root-of-addon>/fastboot/addon/instance-initializers/<name-of-your-initializer>

and in an application:

<root-of-app>/fastboot/instance-initializers/<name-of-your-initializer>

If you’d like to see more detail on this please referr to this EmberCLI ticket by @kratiahuja

github.com/ember-cli/ember-cli

[Fastboot support] Integrate building & serving fastboot in ember-cli

opened 09:41PM - 14 Oct 16 UTC

closed 01:12AM - 12 Nov 16 UTC

kratiahuja

This is a master issue tracking the work to integrate building fastboot in ember…-cli. We can break this issue into smaller ones if needed. Note: This is a backward compatible proposal in `ember-cli` but incompatible with current fastboot ergonomics. **TL;DR:** After this issue is fixed it will allow: 1. Fastboot assets to be built using `ember build` and be performant. 2. Allow a different server (in this case fastboot server) to serve files rather than `ember-cli` serve middleware using `ember serve`. 3. Kill `ember fastboot` command itself. I have a prototype and some of the changes working (building `fastboot/app` and `fastboot/addon`) with `ember-cli`. **Thanks to @stefanpenner for the idea!** ## Motivation [Fastboot](https://ember-fastboot.com) allows ember apps to be rendered on the server side. It renders the initial content of your app allowing your app to be used in SEO usecases. On a very high level, fastboot loads your assets in a Node environment and creates the Ember App once the assets are loaded. It does not do any automatic routing but creates Ember application instance whenever there is a server side rendering request and runs your route to render the initial render in Node. In order for your app/addon to be able to run in a Node environment, it needs to be compatible in such environment. Compatibility includes not doing DOM/window access in Node, making sure you are able to make API requests in Node etc. Therefore an app/addon may need to provide fastboot specific initializers, instance-initializers, services etc that are only applicable in the Node environment and not in the browser. Including them in the browser has performance implication since you will send down more bytes to the client. Currently fastboot builds the app twice and generates a different set of assets for fastboot and browser environments via `ember fastboot` command. Most of the app between the two sets of assets is same except where we want fastboot to override the browser behavior or need fastboot specific handling. Currently `ember fastboot` filters these and generates the two sets of assets. Building different sets of assets (app and vendor files) for different environments cannot guarantee the app works correctly in both environments always. Moreover, `ember-fastboot --serve-assets` command also spins up a node server and serves your assets. This is very similar to what `ember serve` does today. However, we end up forking and creating two parallel worlds with problems such as serving stale assets, creating race conditions during serving and building etc. We want to be able converge the two worlds such that fastboot should be able to specify the last middleware that will be used to serve the assets in fastboot. This helps us not create fastboot commands and keeps the eco-system unified. We want to build these fastboot specific code as an additive asset to the browser that loads in the Node VM in addtion to the the other assets. If it overrides any browser behavior, having the same module id will override the definition in the loader. In order to build fastboot assets in a performant way, we would like to integrate building fastboot into ember-cli. This issue specifically tracks integrating building fastboot in ember-cli. When we need to build more such artifacts, we can extend this to be a generic target solution. ## Solution In order to build the fastboot assets which are an addition to the app and vendor files, we want to define a separate directory structure. This will allow fastboot specific app/addon code to live in its own namespace and does not touch the app and vendor files. For example an addon containing fastboot specific functionality will have a directory structure like: ``` my-addon/ |-- addon/ │ |-- utils/ │ │ |-- foo.js │-- app/ │ │-- instance-initializers/ │ │ |-- error-handler.js │-- fastboot/ │ │-- app/ │ │ |-- instance-initializers/ | | | |-- error-handler.js | | | |-- ajax.js | |-- addon/ | | |-- utils/ | | | |-- foo.js | | | |-- fastboot-utils.js ``` Note: The same applies within an app as well, just that it wouldn't have `fastboot/addon` folder. This allows us to keep fastboot specific functionality in its own namespace and allows us to build fastboot artifact by walking only the subset of the tree rather than walking the whole app and doing filtering (as done right now). After an `ember build`, the generated assets will be: 1. vendor.js 2. app.js 3. app-fastboot.js In the Node VM, we will first load the assets and eval them in the above order. Therefore, if you wanted to override a functionality in fastboot, you can keep the name of the file same in fastboot namespace and will override it when `app-fastboot.js` gets loaded and evaluated. This also guarantees that we do not regress existing ember builds that do not contain the fastboot namespace. ## Tasks This issue tracks the list of changes and public APIs we need to expose for supporting the above strategy in `ember-cli`: - [ ] Support building fastboot/app from app and addons and generate `<app>-fastboot.js` - [ ] Make sure `broccoli-asset-rev` is able to fingerprint these additional assets - [ ] Add `fastboot` as a type of tree in `preProcessTree` and `postprocessTree` - [ ] Expose `treeForFastbootApp` for fastboot addons to add/remove items from fastboot specific trees. This will allow us to add HTMLbars munging based on Ember versions. - [ ] Make sure JSHint is enabled for `fastboot/` - [ ] Expose an API from `ember-cli` to allow an addon to add a middleware to serve assets (See issue [here](https://github.com/ember-fastboot/ember-cli-fastboot/issues/274)). I still need to explore this a bit more. - [ ] Make sure live reload works with fastboot changes. - [ ] Update documentation of ember-cli with the additonal public hooks and building of fastboot assets. - [ ] Update documentation of `ember-fastboot` ## Future We may want to create different types of additional assets in future that are addition to the existing assets. We may want to make it generic such that we could say `ember serve --target fastboot`. ## Working on this issue? I am going to send out a `[WIP]` PR fixing the tasks in the above list. Please feel free to pick any and add it as a comment. cc: @tomdale @stefanpenner @danmcclain @arjan @masonwan @ryanone

Cheers!

rwjblue · May 1, 2018, 8:12pm

Right, you would put them in fastboot/instance-initializers/some-name-here.js.

Topic		Replies	Views
Using FastBoot and localStorage Ember Data	2	1625	May 22, 2017
Difference between initializers and instance-initializers Ember CLI	2	4267	November 17, 2015
Fastboot and file-only deployment environment? Ember CLI	5	1131	May 29, 2018
Ember instance initializer General	0	465	October 15, 2018
Lost application instance when ember build	5	1413	December 3, 2015

Where do Fastboot initializers go?

Related topics