So I'm not sure where exactly I should put this, but I figured "feature requests" is probably most appropriate (as it's not a single "bug", exactly...)
So, the NodeBB forum I am with is full of picky software developers who complain about the forum all the time 
One of the biggest, if not the biggest complaint, is how badly NodeBB drops connection on bad internet connections, namely mobile or WiFi hotspot hopping.
I'd like to post this thread as more of a discussion of how to fix it - I'm not exactly familiar with the codebase, and I don't really know how the best way to handle it would be, but it seems like socket.io, or the implementation NodeBB has of it, breaks badly and often in unreliable conditions (leading to pages failing to load, votes failing to take effect, and the reply/quote buttons failing to have any effect, usually requiring a refresh of the page).
I'll probably be taking a closer look at the client side code, but I'm curious if anyone else has any ideas of how to fix this particular issue - or whether due to socket.io problems, it can be fixed at all.
Agree. It happens a lot on 3g navigation
@exodo said in RFC: Make the forum clients more resilient to bad connections:
Agree. It happens a lot on 3g navigation
Yeah. We have an ongoing issue of NodeBB pegging a CPU core too, and it happens a lot when it does that (we need to restart the nodejs process).
@torn2 said in RFC: Make the forum clients more resilient to bad connections:
Man, we luckily have not had any issues like this. Makes you not want to upgrade and/or make changes. Which version are you guys using???
Bleeding-edge-ish latest, updated from Git. Not sure what we're on right now, don't feel like looking up the thread 
But we've had these issues pretty much since we started using it.
Hey @sloosecannon -- good topic 
In general, the times when connection drops are most noticible are during:
Other real-time things you honestly can't tell, since if someone posts and it doesn't show up right away, it's not really all that detrimental to the end user experience
Now, the former, we really can't do anything about, since if the call to the api route takes awhile, we just have to wait... the latter, we could. A post could be rendered on the client-side, and then stored in the active session while it goes about saving to the backend.
The risk, of course, is that the user might leave the site, at which point poof, goes the transient data.
Not so good 
@julian said in RFC: Make the forum clients more resilient to bad connections:
Hey @sloosecannon -- good topic
In general, the times when connection drops are most noticible are during:
- Page navigations
- Posts
Other real-time things you honestly can't tell, since if someone posts and it doesn't show up right away, it's not really all that detrimental to the end user experience
Now, the former, we really can't do anything about, since if the call to the api route takes awhile, we just have to wait... the latter, we could. A post could be rendered on the client-side, and then stored in the active session while it goes about saving to the backend.
The risk, of course, is that the user might leave the site, at which point poof, goes the transient data.
Not so good
i really dont understand those connections things but the main problem i get on bad connections aka 3g, sometimes on 4g too is that i hit reply and composer doesnt open, i need to reload page and then hit reply again
That is randonmly of course
@julian said in RFC: Make the forum clients more resilient to bad connections:
Hey @sloosecannon -- good topic
In general, the times when connection drops are most noticible are during:
- Page navigations
- Posts
Other real-time things you honestly can't tell, since if someone posts and it doesn't show up right away, it's not really all that detrimental to the end user experience
Now, the former, we really can't do anything about, since if the call to the api route takes awhile, we just have to wait... the latter, we could. A post could be rendered on the client-side, and then stored in the active session while it goes about saving to the backend.
The risk, of course, is that the user might leave the site, at which point poof, goes the transient data.
Not so good
Right - I believe Discourse does something like that as well. And it does indeed have exactly that issue
I'd be interested in a way to debug what exactly has broken down in socket.io when these drops happen - it seems like it sometimes just refuses to reconnect without a page refresh, and I think that's the thing people find most annoying - it's not necessarily the fact that it breaks, it's that it breaks and stays broken!
@baris That would be nice. Also, probably not a bad idea to add some kind of UI cue to indicate that the button has been pressed, and maybe something in the way of error-checking to let people know when the socket is broken (That would be more of a general thing - there are a lot of actions that don't work at all without any kind of feedback - upvoting, scrolling to load posts, IIRC some of the buttons too).
Interesting this topic came back up - just earlier today I saw this on Reddit (mobile) and I liked how they did it. The alert at the bottom slides up to let you know you disconnected and then slides away a few moments after you reconnect.
@psychobunny I like that implementation a lot. It could appear in the little toast window that comes up for "new forum version".
Hmm, so I just found an interesting behavior that might be the cause.
It appears that NodeBB uses the websocket by default, but when the connection fails, it falls back to polling!
It does not appear to reconnect to the websocket after the failure. There's an easy way to see this - open up Chrome's dev tools on a NodeBB site, then kill your network connection.
It starts sending polling requests, and continues even after the connection is re-established!
Perhaps this is the reason that it gets "stuck" and has weird connectivity bugs?
