So I was just at a client demonstration, I took 10 minutes to do a presentation. Meteor app was on the projector.
I had to manually hit refresh in order for things to start working again, and was embarrassing.
I’ve added the 255kb:meteor-status so at least I’ll know to hit refresh…
My app requires a 100% connection to the server at all times– why the hell does Meteor have this behavior on be default?! How do I fix? My agents need to have this screen open with a subscription 24/7/365.
Unfortunately, you’re running into a pretty frustrating part of a lot of unfriendly systems (not) working together. It’s really shitty this should come up in the middle of a client demonstration.
Generally, there’s nothing in the meteor code (or indeed any typical websocket client or server code) that causes inappropriate, unrecoverable or unresponsive connections.
Chrome 57 and later has pretty aggressive backgrounding. Even if their own documentation (https://developers.google.com/web/updates/2017/03/background_tabs) says that they give exceptions of some kinds of processing to websocket applications, who really knows what their policy is at any given moment (I certainly couldn’t get a straight answer from the source code, which is what I usually do to help folks out).
Safari too has powersaving features that may be surprising.
I don’t know how modern Firefox would respond. Firefox 58 ESR notifies you when it does surprising things. So if there was a problem with the browser disconnecting a long-running tab’s connections in an unrecoverable way, it will tell you.
There was an issue about this from a while ago that I could not find. The recommendation for kiosks was to use Firefox’s kiosk mode. That’s what I’d suggest in your case.
As an aside, I’m not a full-time front-end web developer, so my familiarity with these sorts of issues is limited. But one of the things you can be pretty confident of is that Google Chrome isn’t as great as it appears; Google Chrome on Windows (which I suspect may be another aspect of your equation) or Android is even worse. If you can run Firefox 58 ESR in kiosk mode inside an Ubuntu LTS machine (or if you’re really crazy, a modern OpenBSD), you’ll experience the smoothest and most consistent behavior.
In the almost 6 years that I have been building apps with meteor, I have never had an issue with the connection dropping out on an app like this on any browser. This is not a default Meteor behavior. If the connection is disconnected it will automatically attempt to reconnect and continue doing so every so often until it’s successful. The package you are using even allows this you to retry the connection at any point prior to Meteor’s automated reconnect attempt.
All that being said there is always the chance of poor connectivity to any network resource and 100% connection up time is an unreasonable expectation, especially when doing a demonstration over an unfamiliar. Live demos are notorious for network connectivity issues.
Hrmm I suppose I was on their hotel wifi, it’s possible the connection was interrupted.
Will continue to monitor…
Edit: Mmmmm my software is starting to become really sexy… 
Evidence or it didn’t happen 
This is why at my work we bring a server with us to demonstrations, with our own wifi and 4G dongle so if internet drops out the app still functions over local network 
