Spike of alternative fastboot app server
Note - these ideas presented here are from the brain of an unnamed person. We can thank this person.
express
with fastify
. Express is largely unmaintained. Moreover, fastify includes HTTP2 support. This is a direction we need to move in the Ember community.The three primary objects are the components that would be required in order to build a production web server on top of Fastify/Node.js.
This process should be responsible for setting everything up and for communicating with the workers. In general, all information regarding application state should be the responsibility of this process.
Currently there are two external facing APIs, beyond the initialization step:
The cluster master does not fork
child processes by explicitly calling out to a separate entry point, it instead relies on the same entry point and branching in the codebase.
This results in:
Downloader
/Notifier
I've found that conflating these two objects is typically a more convenient API. The Notifier
is often the one who first knows of a new asset, where to find it, and how to get it. The Downloader
is simply a Promise
that resolves once the asset is ready for use. It does not receive any information which means that it must have a stateful sidechannel for where to get information. That tightly couples it with the Notifier
. I'd argue that this is a good thing; making these two pieces of the system aware of each other creates a place to handle debouncing, coordination for time releases, and more.
class DownloaderNotifier {
constructor(options) {
this.distPath = options.distPath;
this.subscriptions = [];
}
subscribe(handler) {
this.subscriptions.push(handler);
return Promise.resolve();
}
trigger(results) {
this.distPath = results.directory;
this.subscriptions.forEach(handler => {
handler(results);
});
}
download() {
return Promise.resolve(this.distPath);
}
}
subscribe
handler to allow for better expansion opportunities.Currently the cluster worker is completely unexposed. This prevents configuration of the worker in any way. Workers would ideally be able to communicate directly with logging APIs, report on their health, be launched directly, and have configuration and state information relevant to them exposed to the HTTP server that they start up.
constructor
.The HTTP server container is exposed as a public API in the project. You can pass in a reference to the HTTP server container you would like to use, already wired up with the configuration that you desire.