What’s wrong with this idea, really? It’s redundant because you can serve HTML to requests with Apache or Ngnix or any other server on the happy path.

What’s right with the idea, really? It’s exactly what the tried and true preferences of developers have been shown to be: getting in the way of the happy path for no reason.

Now you can have build steps and put story points in Jira and do it all on the server where we don’t have to see it, and the success condition is that the text gets served. Both sides can be happy now.

> What’s wrong with this idea, really? It’s redundant because you can serve HTML to requests with Apache or Ngnix or any other server on the happy path.

Overhead, Security, Denial of service to name a few.

You now have two states to track. Is the web-server serving the current version that the web socket is rendering?

Is your monitoring enough? Is your monitoring going to detect if the web-socket server is suddenly taken offline? How do you monitor your web server is alive and ready to serve requests in the time of need?

How do you determine if the socket server is actual offline and not frazzled itself in an event-loop? A stray network packet you never conditioned it for.

If both your web-socket server and the web-server are going to follow the same source of truth for fail-over why not just use the web-server?

The web-server is a tried and true method of serving websites. An application that allows you to easily load balance; tune and enhance with other security features. The best part is than you can actually serve a website without requiring JavaScript.

Enterprise/corporate/country DPI firewalls like to silently block web sockets; any requests you're going to be rendering blank back to the client. Determining if the client is blocked isn't easy and how do you let the clients report an issue if they can't render the support page?

The starting sequence of a web socket is an HTTP request header to an upgrade the connection. Correctly configured DPI firewalls block these upgrade headers so for all you know the connection has been made but the renderer fails silently.

You still need a service to serve the JavaScript fronted so unless you create a WebSocket HTTP server which you've then opened a can of worms; you have a perfectly functional web-server sitting around idly wasting resources.

As I bombard your web-socket server with faux requests slowloris style. Your web-server is alive and as far as it knows your socket server is alive too, how do you determine if the web socket is actually under attack? This adds more complexity in the mix.

It's not wrong per-se. For a infrastructure learning exercise sure. However for anything else it's a waste of time and will cause headaches. The resources and the overhead for it all just isn't worth it. It's a mirage of something that looks opportunistic but isn't.

Furthermore any alterations need testing on both parts. If you were to apply a hotfix for the web-socket side, does this negatively effect the web-server side?

Does it perform the same way in Firefox and Chrome? If Firefox is slower at parsing the JavaScript html json, how are you going to accommodate that?

Article should've mentioned caching, or lack thereof