3 ms·
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 cl
by mrbungie 7y ago
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.
- boomlinde 7y ago> 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.
- vidarh 7y agoYour 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.