As described by Jie in a PR comment:

"""
I tested it without running the underlying storage api running and when a client visits the site, the server crashes:

events.js:141
throw er; // Unhandled 'error' event
^

Error: connect ECONNREFUSED 127.0.0.1:8080
at Object.exports._errnoException (util.js:907:11)
at exports._exceptionWithHostPort (util.js:930:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1077:14)

Could you handle this case as well? Either display no data, or display an error page. The server should still run and later, if the backend layer starts running, and a client visits the page again, it would work.
"""

I see this happening however when doing "npm start" in boreas/server when the boreas/web-layer is not running ("mvn exec:java"), with there not even being an opportunity for the server to come up let alone a client to visit.

Is the right fix here to have the server come up but display some error message to client connections? Or should the server perhaps just fail with a more informative error message that a key component of the backend is missing? The case where the Thermostat web-storage-service goes away is already handled relatively gracefully - it's just if boreas/web-layer is missing that this occurs.

The GUI should show information on jvms monitored by thermostat agents. (process information, pid, start/stop time, user id, java information, main class, command-line arguments, jvm version, etc.)

The GUI should show the hosts and jvms being monitored and allow selection for displaying more info.

The GUI should show the overall CPU usage of the host machines monitored by thermostat agents.

Many dependencies prefer/need commonjs style require() statements to use their api. To better accommodate we should switch from Bower to using Browserify to compile code for front end use. Babel is needed as an intermediate step to convert any jsx code for use by Browserify.

We can also easily automate this with a taskrunner like Gulp/Grunt

GET Requests for a collection should be able to be filtered by jvm or host (depending on collection type) using their unique ids.

The GUI should show the heap information of the jvms monitored by thermostat agents. (heap usage, heap capacity)

The GUI should show the overall memory usage of the jvms monitored by thermostat agents.

The GUI should show information of the host machines monitored by thermostat agents. (host, hardware information, operating system, etc.

The GUI should show the gc information of the jvms monitored by thermostat agents. (how much time each gc takes, etc.)

The GUI should show the overall CPU usage of the jvms monitored by thermostat agents.

The GUI should show the overall memory usage of the host machines monitored by thermostat agents.