Your input is needed!
Right now, if an app errors out while fufilling a request, the FastBoot server returns a 500 HTTP status code and an error message. This is probably the correct behavior for using FastBoot for pre-rendering content.
However, if you're serving FastBoot pages to the end user, this is problematic. If you happen to have a route that crashes on certain
circumstances, but only on Node—for example, maybe it inadvertently accesses localStorage
—you'd rather serve the app to the user because
it will work when rendered in the browser. It's not just bugs though—sometimes you may encounter a transient error on the server, and you
still want to give the client a "second chance" to try rendering the route client-side.
I want to introduce a flag for the FastBoot server to control whether errors during rendering are considered a fatal 500 error, or if they should be "swallowed" and the empty HTML page be served to the user with a 200 status code.
swallowErrors
recoverFromErrors
alwaysServeHTML
resilient
- Other suggestions welcome!
I've already extracted a more-robust, multiprocess FastBoot app server from fastboot-server
; it lives here: <https://github.com/ember-fastboot/fastboot-app-server`.
We can now get rid of the "app server" component of fastboot-server
. Because the name "server" is pretty misleading here, I want
to rename it from fastboot-server
to something else. So the question is: what should we name it?
Here's what it does
┌────────────────────────────────────────────────┐
│ ember-cli-fastboot │
└────────────────────────────────────────────────┘
│
┌ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─
Ember App (dist/) │
└ ─ ─ ─ ─ ─ ┬ ─ ─ ─ ─ ─
│
▼
┌────────────────────────────────────────────────┐
│FastBoot App Server │
│ │
│ ┌─────────────────┐ │
│ │ express │ │
│ │┌───────────────┐│ ┌────────────────────┐ │
│ ││ middleware ◀┼─────│ fastboot-??? │ │
│ │└───────────────┘│ └────────────────────┘ │
│ └─────────────────┘ │
└────────────────────────────────────────────────┘