Get the NATS Newsletter
News and content from across the community
Week of August 22 - 28, 2022
A short list of  announcements, blog posts, projects updates and other news.
Official releases from NATS repos and others in the ecosystem.
GitHub Discussions from various NATS repositories.
nats-server - Nats self publish a scheduled cron message?
nats-server - Consumer Filtering Performance
nats.go - Why not another approach
New or updated examples on NATS by Example .
Regional and Cross Region Streams - Supercluster and Cluster variants
Iterating Over Multiple Subscriptions - Rust
Questions sourced from Slack, Twitter, or individuals. Responses and examples are in my own words, unless otherwise noted.
*_advertise options do?There are a few network address advertising options that may be important depending on your NATS deployment requirements. Each of these are defined in the server configuration document, but have been a recent topic of conversation.
client_advertise can be set an alternative to the host/ port or listen options that define the interface on the host that NATS server will bind to. The advertise address is the one that clients can use when establishing a connection. This is often different if NATS is running behind a NAT gateway or proxy.
cluster { advertise } is the equivalent of the client_advertise but scoped to the cluster block and impacts members in the cluster. nats-route:// URLs must be set to used this address.
cluster { no_advertise } is an option that prevents sending a server’s host:port information (or any of the other members in the cluster) to the client. This is necessary when these URLs are internal and are not addressable from the client’s perspective. In this case, the client must rely on the pre-defined advertised addresses.
gateway { advertise } is the equivalent of the client_advertise and cluster { advertise } options, but scoped to the gateway block and impact gateway connections.
leafnodes { advertise } follows the same pattern, scoped to the leafnodes block and impact leafnode connections.
leafnodes { no_advertise } is equivalent to the cluster { no_advertise } option for leafnode connections.
websocket { advertise } follows the same pattern, scoped to the websocket block.
In addition to these server configurations, some client implementations have the option of ignoring gossiped server URLs (such as with Node and Deno) and thus only rely on the explicit set of URLs provided for the client connection.
Yes! Synadia provides NGS which is a NATS service that is deployed across multiple regions and clouds. Sign up for free to try it out.
nsc tool?A user is created using the nsc add user subcommand. In additiont to the JWT and NKey, this command outputs a credentials file to the path $NKEYS_PATH/creds/<operator>/<account>/<user>.creds. If the $NKEYS_PATH environment variable is not explicitly set and the --keystore-dir option is not used, the $NKEYS_PATH has a different default depending on the OS.
Using the nsc env command, you can see what the path is. However, currently there is no way to refer to reference this env variable programmatically, for example nsc env NKEYS_PATH to output the value.
A workaround to referencing the existing credentials file on disk, is to [re-]generate the file using the following command.
nsc generate creds -a <account> -n <user>
This will output the credentials to stdout by default.
Over a year old, but here is the most recent discussion. Definitely worth a page in the docs.
NATS can be deployed as a single server on a node, a cluster of nodes, a supercluster of clusters, and even further extended using leaf nodes. Given this flexibility of topology which can be spread out across multiple regions (including continents), as well as addressing the realities of a distributed system, it is critical that location transparency is handled for clients, but the interactions are also optimized.
This optimization comes in the form of NATS calculating round-trip time (latency) between clients that publish messages and those that subscribe/reply to messages. For example, if there are two clusters, one deployed in us-east and one in us-west each with a subscription implementing a service (request-reply), if a client connects and publishes a message in us-east, NATS will route the message to the service in us-east if available, otherwise it will transparently fallback to the one in us-west.
It my be more appropriate to call NATS latency-aware which happens to correlate with geography.
News and content from across the community