back
3 comments
The fact that it's not a server in your browser, but a client to a server on the backend makes it less of a server in your browser
No true Scotsman detected.

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.
are pub-sub servers less of a server? also, a proxy server is itself a server.
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.

If its a server or not is less interesting than the server [like] features such a thing could give us. The most interesting one of which imho is:

Who is responsible for my actions?

(If its anyone besides me it sucks)