NATS Weekly #41

Week of August 22 - 28, 2022

🗞 Announcements, writings, and projects

A short list of  announcements, blog posts, projects updates and other news.

⚡Releases

Official releases from NATS repos and others in the ecosystem.

• nats.deno - v1.8.0
• nats.ws - v1.9.0
• nats.js - v2.8.0

💬 Discussions

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
• k8s - helm chart for nats-operator

🧑‍🎓 Examples

New or updated examples on NATS by Example.

• Regional and Cross Region Streams - Supercluster and Cluster variants
• Iterating Over Multiple Subscriptions - Rust

💡 Recently asked questions

Questions sourced from Slack, Twitter, or individuals. Responses and examples are in my own words, unless otherwise noted.

What do the *_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.

Is there an official supported managed service for NATS?

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.

How can you programmatically get user credentials using the 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.

Is the NATS server FIPS compliant?

Over a year old, but here is the most recent discussion. Definitely worth a page in the docs.

What does it mean that NATS is geo-aware?

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.