-
Notifications
You must be signed in to change notification settings - Fork 605
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make / work under FastBoot #1937
Conversation
r? @smarnach (rust_highfive has picked a reviewer for you, use r? to override) |
fb0fca0
to
024040c
Compare
This commit adds a transparent cache called "fetcher" to prevent making 2 XHRs (both from the frontend to the backend).
https://api.emberjs.com/ember/3.14/classes/Route/methods/setupController?anchor=setupController > If you implement the setupController hook in your Route, it will prevent this default behavior.
@carols10cents @jtgeibel Would any of you be able to take this review? Frontend reviews tend to take me ages, since I just don't know JS and Ember very well, and currently I don't manage to find the time. (I hope this will get better again next year.) |
No problem! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for continuing to work on enabling fastboot! When I run the frontend locally with USE_FASTBOOT=1 npm run start:local
, the homepage is loading with crate info whether I visit it with JavaScript on or off. Very neat!!!
I have a few questions about expected behavior:
- When I have JavaScript disabled, I see the frontpage content, but I also see the "This site requires JavaScript to be enabled." still at the bottom of the page. Is this intentional? Screenshot:
-
When I have JavaScript disabled and try to log in, I see a full-page error that says
window.open is not a function
. I think we need JavaScript in order to log in? What are the plans for converting this? Could we show a "Logging in requires JavaScript" error message instead? This is also currently a problem with master when fastboot is enabled, but because the rest of the page doesn't fill in with data, it's less noticeable ;) When fastboot is off, I only get the "This site requires JavaScript to be enabled." message, without a login link. -
This happens on master too, so perhaps this PR isn't meant to fix this issue, let me know. When I log in, it works, but as the popup window is closing I see this error saying
window.close is not a function
:
The popup window does close though, and I'm successfully logged in as I expect. It's just strange to see an error message briefly.
When this happens, in the frontend logs in the terminal, I see:
GET /api/private/session/authorize?code=[redacted]&state=[redacted] 200 3.041 ms - 49
Error while processing route: github-authorize window.close is not a function TypeError: window.close is not a function
at Class._callee$ (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/cargo/routes/github-authorize.js:45:1)
at tryCatch (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:63:1)
at Generator.invoke [as _invoke] (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:337:1)
at Generator.prototype.<computed> [as next] (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:96:1)
at tryCatch (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:63:1)
at invoke (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:139:1)
at /var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/vendor/regenerator-runtime/runtime.js:147:1
at tryCatcher (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/rsvp.js:200:1)
at invokeCallback (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/rsvp.js:372:1)
at publish (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/rsvp.js:358:1)
at /var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/ember-testing/ext/rsvp.js:14:1
at invokeWithOnError (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/backburner.js:214:1)
at Queue.flush (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/backburner.js:125:1)
at DeferredActionQueues.flush (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/backburner.js:278:1)
at Backburner.end (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/backburner.js:410:1)
at Timeout.Backburner._boundAutorunEnd [as _onTimeout] (/var/folders/qc/0ry2bjtd7wd9q8r1c7wylplr0000gn/T/broccoli-44493o2G1SkH1hxhM/out-418-broccoli_merge_trees/assets/backburner.js:372:1)
at listOnTimeout (internal/timers.js:531:17)
at processTimers (internal/timers.js:475:7)
2019-12-16T15:22:21.733Z 200 OK /authorize/github?code=[redacted]&state=[redacted]
The nginx file is still only using fastboot for /policies, so I haven't tested this on staging yet.
Yes. Login, logout and "This site requires JavaScript to be enabled." message are known issues and tracked by #1811. I'd like to keep them open and address them separately, instead of having a big PR. Let me know if you (or the team) are not comfortable regrading the approach. Regarding nginx.conf, can you review #1907? I'd like to have him changes on master first to avoid conflicts. |
Oooops. You caught me-- I haven't actually read through #1811 😆🤭 What you're doing is fine ❤️
#1907 has been merged in so I merged master into this branch and I'm now deploying this branch to staging to try the different modes out :) |
Hmmm, so I have 9b4aaf5 deployed to staging, which contains the nginx changes, and However, when I visit https://staging.crates.io/ with JavaScript disabled, I'm seeing only the "This site requires JavaScript to be enabled." notice. I'm not sure why... |
Yeah, that's odd and I can repro the issue. Seems CloudFront is not caching and the response is coming from Express. Then it should be server-rendered, but it's not.
|
Yeah I have no idea either. I'm going to deploy master to staging now, in prep for doing a deploy to prod. I'll put staging back to this branch with the env var set when I'm done! |
Okay. Can you add Ruby's strings have encodings and POSIX's locale-related environment variables affect the default encoding. It worked for me at least. |
Ok, I have 9b4aaf5 deployed to staging right now, and I've set the
|
Here is mine: https://fathomless-island-39956.herokuapp.com/ I think @jtgeibel might have a working environment as well. |
@jtgeibel when you get a chance, since you have access to staging now, could you compare your setup and staging's and see if I missed any environment variables or anything? |
@carols10cents I've pushed this PR to my environment, and added you to the app on Heroku. Are things working for you at https://jtgeibel-staging-crates-io.herokuapp.com/ ? I've done some fastboot testing in this environment before, but don't think I've tried this particular PR yet. It seems to be working fine for me. I'm pushing this back to staging now as well, to see if I can replicate the issue you were seeing there. |
I've added Papertrail to staging and have been looking at the logs. It looks like in the staging environment, the request is coming with a path of |
@jtgeibel Interesting. Seems like it is.
@pietroalbini Do we really need the default root object? |
There is a concern that setting the default root object to index.html for the crates.io webapp causes Fastboot to break: rust-lang/crates.io#1937 (comment) This adds a temporary feature flag to remove the default root object just from staging, without affecting production. After testing is done the feature flag will have to be removed, either disabling or enabling the root object both on staging and production.
@Ksys I don't think so for the webapp. Removed the root object on staging (without touching prod), the change should propagate in around 15 minutes. |
It's working!!! Thank you all for helping to figure this out!! I also tested unsetting USE_FASTBOOT and everything works fine, so I think the cloudfront root object change is safe to make on prod, and this is safe to merge. @bors r+ |
📌 Commit 9b4aaf5 has been approved by |
Make / work under FastBoot This PR adds a transparent cache called "fetcher" to prevent making 2 XHRs (both from the frontend to the backend).
☀️ Test successful - checks-travis |
index: Replace loading spinner with list item placeholders #1937 changed the data loading code of the `index` route to load the summary data in the `model()` hook again. That is fine when using fastboot, but without fastboot it is currently resulting in an ugly loading spinner page before the real page content gets rendered. This PR replaces the loading page with rendering the real page directly and showing placeholders until the real data is available. The new approach is still compatible with fastboot due to the use of `deferReadiness()`. ![loading](https://user-images.githubusercontent.com/141300/80317190-98050780-8802-11ea-8596-8d9f9ee05545.gif) r? @locks
This PR adds a transparent cache called "fetcher" to prevent making 2 XHRs
(both from the frontend to the backend).