Culmination of hodgepodge realizations of WebSockets (Circa July 2019)

I've read many articles about WebSockets the past month, and each article gives one to several tidbits of information, but not enough to answer all my questions.

Environment:
CentOS Linux release 7.3.1611 (Core)
node v8.16.0
nginx version: nginx/1.12.2

Here's the culmination of what I've learned so far.  I am using Node.js with Express, "ws" for the Node WebSocket library, and native WebSocket javascript for the front-end.

1. So many articles to read!  Some of the early articles I read taught how to code WebSocket connections, frames, listeners, etc yourself!  This is good reference but definitely not ideal to actually do! There's many libraries out there that can do this for you  I eventually chose "ws" as I discussed in my last post.
• The only con I see right now it doesn't have a fallback method to long-polling like some libraries available (i.e. socket.io).   This doesn't concern me because WebSockets are supported by all major browsers - please reference number 7 below for more thoughts.
2. Not explicitly clear if you are supposed to keep client connections open and re-use them as needed (or open a new one for each request).  
• The typical use case for keeping client connection open and re-use them is for a chat type of application.
• My use case (where I am opening a WebSocket connection each request) is that "occasionally" there will be requests that take "longer than usual", and where it used to be HTTP there would be a HTTP response timeout on the web server level (set at 5 mins).  To not have to keep increasing this timeout, a different solution was needed - polling, WebSockets, etc.  WebSockets were chosen for several reasons which I won't go into here.
3. The Node backend is clustered with one instance per CPU, and a WebSocket Server is running alongside each Node Server instance, so it can handle many WebSocket client connections concurrently.  If you want a large number multiple concurrent WebSocket connections concurrently, take a look at this article.
4. The WebSocket protocol discusses the concept of ping/pong messages for the server to know each client is still connected, as well as conversely each client connection can still communicate with the server (i.e. Wifi connection terminated unexpectedly):
• If the WebSocket Server sends a ping or pong, then the client should have to be able to recognize a ping/pong was sent, and respond, but there is no client side javascript code that can send or recognize/receive ping/pong frames, it's either supported by the browser or not.  
• As referenced from this article - “ping/pong frames” are used to check the connection, sent from the server, the browser responds to these automatically. 
• This article was helpful in teaching me that "Unfortunately, the Websocket protocol does not provide a similar method for the client, to find out if it is still connected to the server. This can happen, if the connection simply disappears without further notification. In order to have the client recognize this, some Javascript code has to be added to the client code responsible for the Websocket".
• Since my application controls both client and server code, adding in a specific header/metadata in a web socket message with `WebSocket#send()` vs using `WebSocket#ping()` can be used to implement a heartbeat. 
• This article - helped me build a heartbeat system with messages.
• During server development testing, I noticed that the heartbeat message was sometimes sent to the client and sometimes not:
• Noticed that if paused in debugger, the setInterval function used for sending a heartbeat message from server -> client wasn't working, since the worker that is paused (so the heartbeat from server -> client is NOT sent).
• If setTimeout(sleep) function was enabled (simulating actual work being perform), the setInterval check DOES RUN for the worker (so the heartbeat from server -> client is sent).
5. Web Server configuration needs configuration to:
• Allow a tunnel to be set up between a client and a backend server.  
• Web Server configuration
• For nginx to send the Upgrade request from the client to the backend server, the Upgrade and Connection headers must be set explicitly, as well as the proxy_http_version 1.1 directive.  Once this is done, NGINX deals with this as a WebSocket connection.  
• https://www.nginx.com/blog/websocket-nginx/
• http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version
• Here's some documentation with Apache Http Server - but I did not personally test this.
• Just how long should you keep the connection timeout to on the web server?  I found some articles that said 7 days, 1 day, maybe you can keep the default web server http read timeout if you have ping/pong/heartbeats sent constantly every minute or so.
6. This repo had a great explanation of all the various WebSocket libraries out there.
7. WebSockets are supported by all the major browser,  but Internet Explorer (11) still has a default maximum number of client connections at 6.
8. Easiest to understand guide were the WebSockets API documentation by mozilla.org.