-
-
Notifications
You must be signed in to change notification settings - Fork 335
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
Jordigh/add websocket #973
Conversation
--inspect-brk is useful if you want to debug something during startup
This self-test isn't perfect because we're running it from the backend instead of the frontend. Conceivably the backend might have trouble resolving its own url. Eventually we should move this test or something like it to something that executes in the frontend.
app/client/models/AdminChecks.ts
Outdated
extra headers in order to work. Sometimes a reverse proxy can | ||
interfere with these requirements. See <a | ||
href="https://support.getgrist.com/self-managed/#how-do-i-run-grist-on-a-server">this | ||
documentation</a> for more explanation. |
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.
This isn't correct, but I just realised that grainjs is our own thing. Is there an easy way to put a link here? I'm not sure how to cross-reference otherwise.
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.
Maybe makeLinks
from links.ts
?
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.
That ui2018
in the module path doesn't inspire confidence. Is that really the best way? 😕
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.
No, it's the easy way.
The best way would be to change the details to be DomContents
instead of strings. GristTooltips.ts
is a good example of largely static blocks of text comprised of DOM nodes.
It'll require a bit of refactoring since details are currently strings, but it shouldn't be much if you're up for it.
One thing to watch out for would be import paths. The rule of thumb is client code (e.g. anything dependent on grainjs) goes in client/
; server code goes in server/
or gen-server/
; and anything that's shared across client and server goes in common/
.
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.
I think it might be worth it, might try this tomorrow. I may like to add more links for other explanations here. Thanks!
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.
Can you defer that bit? AdminChecks changes in a parallel PR. Put small "add more explanation link to websocket probe" card in the kanban for now?
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.
Right-o, will do.
0c9bed9
to
556a197
Compare
app/client/ui/AdminPanel.ts
Outdated
@@ -145,6 +165,7 @@ export class AdminPanel extends Disposable { | |||
} | |||
|
|||
private _buildSandboxingNotice() { | |||
// TODO: reconcile with AdminChecks text for sandboxing. |
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.
Flagging this TODO in case it's something to sort before merging :)
NODE_PATH=_build:_build/stubs:_build/ext nodemon ${NODE_INSPECT:+--inspect} --delay 1 -w _build/app/server -w _build/app/common _build/stubs/app/server/server.js & | ||
NODE_PATH=_build:_build/stubs:_build/ext nodemon ${NODE_INSPECT} --delay 1 -w _build/app/server -w _build/app/common _build/stubs/app/server/server.js & |
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.
What does this change do? :)
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.
It's unrelated, but I explain it in the best place to hide sensitive secrets: in the commit message.
In case you didn't know (and sorry if you did), --inspect
will start and run a Node process that you can attach a debugger, whereas --inspect-brk
starts the process but immediately sets a breakpoint at the entry point of execution. The latter is helpful if you want to start debugging a process from the very beginning. In the case of Grist, I wanted to debug initialisation to understand how the server starts listening for websocket connexions.
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.
To add something about that: using yarn start:debug
is not perfect as it requires to close the debugger for letting nodemon restart the node process when you change some piece of code… That's probably a nodemon / node limitation.
Unless there's something new since the last time I used this command.
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.
Few remarks, with the hope they can be relevant :).
name: 'Can we open a websocket with the server', | ||
apply: async (server, req) => { | ||
return new Promise((resolve) => { | ||
const url = new URL(server.getHomeUrl(req)); |
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.
Unless I am wrong, with #915, this will have to be changed to getHomeInternalUrl
. Or does it mean to reach the reverse-proxy, to test whether it is configured to handle correctly the websockets?
My comment will probably not require any action in any case, though, especially if you merge before the above PR.
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.
Yes, the purpose was to test the reverse proxy.
This test has a bigger problem, though: it runs all in the backend. We plan to fix this and other connectivity tests by making them run in the frontend.
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.
Thanks! I was indeed wondering if that was not a better idea to handle that client-side :)
url, | ||
}; | ||
ws.on('open', () => { | ||
ws.send('Just nod if you can hear me.'); |
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.
Does it have any effect? It looks like the server expects serialized JSON.
In case you want to know whether the server can respond, I noticed that the server sends a message right after the connection is open, with content like this one:
{"serverVersion":"unknown","settings":{},"type":"clientConnect","clientId":"8381953b21f26c76","profile":{"email":"[email protected]","name":"You"},"needReload":false}
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.
Maybe I should augment or change the test to not be complete until a response message is received. I don't particularly care about the shape of the messages, just that a message happens.
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.
I see. What are the benefit of sending this message? Is there something that would prevent the promise to be resolved the line after? Or is this for printing something in the server logs for the administrators?
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.
I reasoned that if for some reason a message couldn't be sent, the error event would be triggered. I'm not sure if that's how the WS implementation works, though.
a771297
to
31bd2dd
Compare
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.
Thanks @jordigh!
d564d1d
to
58de132
Compare
31bd2dd
to
52ecefb
Compare
52ecefb
to
d0a494c
Compare
Adds a simple websocket test.
I tested this on my test instance by enabling and disabling headers in nginx. The test passed and failed accordingly.