As per the docs, the NATS server design is a "server first" approach, regarding protecting against "lazy clients". Lazy clients are just booted under poor performance scenarios.
Due to this, I have internalized an assumption that anything connecting from past the edge should not connect directly to the NATS server, but should instead access some middle layer service point that manages and maps the more poorly performing external connections through internally initiated connections to the NATS server.
For example, consider a client service node on a remote customer facility that accesses back end services that are serviced over NATS in some form.
Is my stated assumption true in a VERY STRICT sense, such that it is NEVER advisable for that remote node to connect to a NATS server directly, even given a low number of possible client connections AND a stable network service to those facilities?
Or, is it ok-ish to connect directly from that remote node IF, and ONLY IF, I have a known solid infrastructure (low latency, high bandwidth, dependable, etc).
Finally, how about if the path to that remote node is not a very solid network service? Specifically, is it better to A) as I described, use an intermediary service on the back-end for managing the end point connection requests and passing them along over internal connections, or B) is it preferred to just let it connect directly to the server and let NATS boot it as needed, then use a re-connect on drops approach to keep the connection up as best as it can?
A good example here is a mobile endpoint, which could be up and down regularly for various reasons and due to no fault of the device or infrastructure at all.
Currently, I am designing every NATS solution as a "backend connections only" design. If this is overcomplicating my designs needlessly, of course I want to stop forcing that design constraint. :)
