To clarify: there absolutely is a server in your browser. You can see its implementation in the `socketMessageListener` function. The fact that you choose to call it "shooting" instead of "serving" does not change that.
My definition would be if it’s largely sitting around doing nothing until a request comes in, and its job is to answer and service those requests, then it’s a server.
By extension of that argument you could argue that no server is a true server:
The fact that it's not a server in the _X_, but a client to a [_Y_ in [Database, DNS, Router, Caching Server, Search Server, REST API, etc]]_ on the _Z_ makes it less of a server in the _X_.
Maybe we should stop using the word "server" and use "client graph", or just continue accepting that there are different layers in a system.
> By extension of that argument you could argue that no server is a true server
No, it couldn’t. For example, I could say that nginx is a server on my computer, and it would be true because it’s running on my computer and is accepting connections from clients, regardless of whether it’s a client to some other service. My browser isn’t.
Why stop using the word ”server”? Just stop watering it down and the meaning will be perfectly clear.
Your confusion is because you assume the requests have to come in via individual sockets, but several distributed designs have servers connect to a frontend and wait for requests instead of having the frontend connect. Many servers are also clients of another service.
E.g. Mongrel2 works that way.
It has the advantage that your reverse proxy does not need configuration changes to know how many processes are available - it only knows which backend servers have connected and not time out. Some such designs will also explicitly have the server do an RPC in to the frontend proxy requesting a request; doing that then also has the advantage that the backends effectively rate-limit themselves by placing themselves in the ready queue when they have capacity, and all you need to know to see if you need more backend capacity is to monitor how deep the ready queue is.
It's waiting for a request to serve content over a network.
Sounds like a server, just using a different network configuration than you're used to, namely WebSocket listening in a browser's JS environment instead of raw TCP listening in a non-browser environment.
The fact that it is not listening on an incoming network port makes it less of a server IMO. Proxies still proxy things back to another server that is listening for TCP connections, not to a client that has previously initiated a connection to the proxy.
A traditional proxy server is a server and a client. A server to the downstream clients, and a client to the backend servers.
Pub-Sub depends on the specific implementation. But anything with an open network socket listening for incoming connections I'd call the server, and anything making outbound connections I'd call the client. In some implementations only the broker is the server. In others every node is a server as they're all listening for multicast discovery messages.
Isn't this pretty much a proxy, and like how nearly production environment on the web works? I don't see how this is any different than using Nginx or Apache in-front of your "server."
IMHO, if the application is waiting for request to be initiated by a client, and then fulfills the request to the client, it's a server. The networking topology is really something totally different...
