Add a USE_FASTBOOT=staging-experimental mode
#1907
Conversation
|
r? @sgrif (rust_highfive has picked a reviewer for you, use r? to override) |
|
As like #1788, this is another PR we can simplify by moving some routes under /api. |
Yes, I would love to do that, but this will require coordination with someone who has access to the GitHub settings for rust-lang to update the oauth settings. We would need to (on both production and staging):
|
|
To clarify, my last comment applies to the |
jtgeibel
force-pushed
the
fastboot-staging-experimental
branch
from
4c33f00 to
bf570ca
Compare
|
I've updated this PR to remove the hack for the 3 session routes, in anticipation of #1918 landing. Since this is an experimental runtime flag, there is no need to land these PRs in a particular order. |
This script is reference from `package.json` and devlopment should behave the same as production.
Make /install work under FastBoot Will add nginx.conf change after #1907. Early feedback is welcome!
Explicitly default to an empty value, to work with `set -u`.
|
I think the logic in On master (3e5dd28)The behavior on master is what I expect. No fastbootWhat I think is "without any fastboot" if I use (livereload hasn't been working for me for a while but I don't think that's relevant) Fastboot only on some pagesWhat I think is "with fastboot for /policies": I think fastboot is on because it says "App is being served by FastBoot" (I hope that's not lying to me!) and because the format of the logs is what we talked about in #1908. On this branch (32a2295)No fastbootIf I try the same steps as I did on master, this is what I see: I didn't expect to see "App is being served by FastBoot", but I do. Fastboot only on some pagesIf I try the same steps as I did on master, this is what I see: I expected fastboot to be on, but this looks like what I see on master when fastboot is off. Fastboot staging experimentalSimilarly, I expected to see signs fastboot is on here, but I don't: So this feels backwards? I've also deployed this to staging, will update on what I'm seeing there next. |
|
I have this on staging and I set USE_FASTBOOT=staging-experimental... I'm not sure what I should expect to be seeing differently than when I think it's working though, because when staging has USE_FASTBOOT=staging-experimental and I log in, I briefly see an error in the popup window. In the logs on heroku when this happens, I see: But I do get logged in 😂 I know we don't have everything working under fastboot yet, so does this mean fastboot is enabled? I am seeing log lines like: when I do a hard reload with When I have When I unset So I think the nginx stuff is working for production-like environments? Let me know if there's anything else you think I should check. |
|
Good catch. The web/production stuff should be working correctly (sans
stuff that hasn't been updated for fastboot yet). For the ember.sh script
(local development) I definitely forgot to swap the branches when I
inverted the condition in the if statement.
Since local testing doesn't go through nginx, setting the variable to any
value will act like staging-experimental does on Heroku.
I'll push a fix for that once I get home tonight. I'll also update the PR
description to document the difference in behavior between the 2 scripts.
…On Thu, Dec 5, 2019, 16:28 Carol (Nichols || Goulding) < ***@***.***> wrote:
I have this on staging and I set USE_FASTBOOT=staging-experimental... I'm
not sure what I should expect to be seeing differently than when
USE_FASTBOOT=1 though?
I think it's working though, because when staging has
USE_FASTBOOT=staging-experimental and I log in, I briefly see an error in
the popup window. In the logs on heroku when this happens, I see:
2019-12-05T21:02:15.652152+00:00 app[web.1]: Error while processing route: github-authorize window.close is not a function TypeError: window.close is not a function
2019-12-05T21:02:15.652225+00:00 app[web.1]: at o.<anonymous> (/app/dist/assets/cargo-344fe2ad42eb900078e166e1e7a8ab40.js:213:33)
2019-12-05T21:02:15.652228+00:00 app[web.1]: at r (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:47:138)
2019-12-05T21:02:15.652230+00:00 app[web.1]: at Generator._invoke (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:43:7)
2019-12-05T21:02:15.652233+00:00 app[web.1]: at Generator.e.<computed> [as next] (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:47:317)
2019-12-05T21:02:15.652235+00:00 app[web.1]: at r (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:47:138)
2019-12-05T21:02:15.652237+00:00 app[web.1]: at t (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:47:398)
2019-12-05T21:02:15.652239+00:00 app[web.1]: at /app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:49:63
2019-12-05T21:02:15.652241+00:00 app[web.1]: at l (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:3431:25)
2019-12-05T21:02:15.652243+00:00 app[web.1]: at v (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:3439:9)
2019-12-05T21:02:15.652246+00:00 app[web.1]: at g (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:3437:43)
2019-12-05T21:02:15.652248+00:00 app[web.1]: at e.invokeWithOnError (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:1596:275)
2019-12-05T21:02:15.652250+00:00 app[web.1]: at e.flush (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:1589:147)
2019-12-05T21:02:15.652252+00:00 app[web.1]: at e.flush (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:1601:15)
2019-12-05T21:02:15.652255+00:00 app[web.1]: at e.end (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:1609:9)
2019-12-05T21:02:15.652257+00:00 app[web.1]: at Timeout._boundAutorunEnd [as _onTimeout] (/app/dist/assets/vendor-bf6f058822ccaed151acd51fae04766b.js:1605:388)
2019-12-05T21:02:15.652259+00:00 app[web.1]: at listOnTimeout (internal/timers.js:531:17)
2019-12-05T21:02:15.652262+00:00 app[web.1]: at processTimers (internal/timers.js:475:7)
2019-12-05T21:02:15.862734+00:00 app[web.1]: 2019-12-05T21:02:15.862Z 200 OK /authorize/github?code=[...]&state=[...]
2019-12-05T21:02:15.922219+00:00 app[web.1]: measure#nginx.service=1.196 request_id=44befcc7-5f10-4603-bf88-96e115ce1a60
2019-12-05T21:02:16.002594+00:00 app[web.1]: at=info method=GET path="/authorize/github?code=[...]&state=[...]" request_id=44befcc7-5f10-4603-bf88-96e115ce1a60 fwd="[...]" user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:73.0) Gecko/20100101 Firefox/73.0"
But I *do* get logged in 😂 I know we don't have everything working under
fastboot yet, so does this mean fastboot is enabled?
I am seeing log lines like:
2019-12-05T21:12:44.911018+00:00 app[web.1]: 2019-12-05T21:12:44.910Z 200 OK /crates
when I do a hard reload with USE_FASTBOOT=staging-experimental, as I
expect.
When I have USE_FASTBOOT=1, I only see log lines that look like that when
I go to /policies or /install, and logging in doesn't produce any errors.
When I unset USE_FASTBOOT, everything indeed looks disabled.
So I think the nginx stuff is working for production-like environments?
Let me know if there's anything else you think I should check.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1907?email_source=notifications&email_token=AAAFNKR3D6FSIZT3KITR7E3QXFW6ZA5CNFSM4JO5BNBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCGVVI#issuecomment-562326229>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAFNKWAKNFTUNFLWM3MTWLQXFW6ZANCNFSM4JO5BNBA>
.
|
|
@carols10cents I've updated
If you disable JS you should notice a bigger difference with With JS enabled, Ember will also load data from the backend once it has booted. This means that bugs in our FastBoot implementation may generate incomplete static HTML, but as soon as Ember loads the data is quickly populated making it difficult to see the difference. |
Aha, that's what I was missing, oops! Just tested locally with the last commit and it works as I'd expect now!!! @bors: r+ |
|
📌 Commit 8e02c1e has been approved by |
…s10cents Add a `USE_FASTBOOT=staging-experimental` mode This adds a new mode to the `USE_FASTBOOT` environment variable. The logic is now: * When deployed on Heroku (staging or production - via `script/start-web.sh`): * If `USE_FASTBOOT=staging-experimental` then non-backend requests are sent to FastBoot. * If `USE_FASTBOOT` is set and non-zero length, FastBoot is enabled only for allowed paths. * Otherwise (`USE_FASTBOOT` is not set, or is zero length), FastBoot is disabled. * When doing local development (via `script/ember.sh`): * If `USE_FASTBOOT` is set, all (initial) frontend requests are served via FastBoot. This is equivalent to `staging-experimental` above. * If `USE_FASTBOOT` is not set, FastBoot is disabled. Because our development environment doesn't go through nginx, it isn't possible to support the "FastBoot is enabled only for allowed paths" mode. However, once the frontend has booted, all further requests hit the backend (unless JS is disabled, then every client navigation results in a new request served via FastBoot).
|
☀️ Test successful - checks-travis |
In production we're currently returning a 502 Bad Gateway for `/policies`. I intend to merge this and deploy to production shortly. This bug was introduced in rust-lang#1907. The bad check always evaluated to true. An explicit check for an empty string is added as well. I've tested this locally with `erb` and different values and the generated configuration is now working correctly.
Fix fastboot check in nginx erb template In production we're currently returning a 502 Bad Gateway for `/policies`. I intend to merge this and deploy to production shortly. This bug was introduced in #1907. The bad check always evaluated to true. An explicit check for an empty string is added as well. I've tested this locally with `erb` and different values and the generated configuration is now working correctly. r? @jtgeibel
This adds a new mode to the
USE_FASTBOOTenvironment variable. The logic is now:script/start-web.sh):USE_FASTBOOT=staging-experimentalthen non-backend requests are sent to FastBoot.USE_FASTBOOTis set and non-zero length, FastBoot is enabled only for allowed paths.USE_FASTBOOTis not set, or is zero length), FastBoot is disabled.script/ember.sh):USE_FASTBOOTis set, all (initial) frontend requests are served via FastBoot. This is equivalent tostaging-experimentalabove.USE_FASTBOOTis not set, FastBoot is disabled.Because our development environment doesn't go through nginx, it isn't possible to support the "FastBoot is enabled only for allowed paths" mode. However, once the frontend has booted, all further requests hit the backend (unless JS is disabled, then every client navigation results in a new request served via FastBoot).