Using NATS with .NET Aspire

If you’re building a cloud-native application using a scalable cluster of microservices, you’re going to need a way for those services to communicate. Traditional API calls work well for tightly coupled code, but what if you’re building an application that scales its edge separately from its core, or that brings in information from across the internet?

This is where message-oriented architectures become necessary. Services source events, which are then distributed to functions that can respond to those events. Those events are encapsulated in messages, along with relevant data, to deliver everything needed for a service to process that event. We often think of this as a common Internet of Things design pattern, but it’s applicable across many different types of enterprise applications.

Messaging in cloud-native code

Basic publish-and-subscribe messaging architectures are relatively simple to build and use, with basic functionality built into most development frameworks. Things are quite different at scale, with message brokers and other middleware necessary to manage, queue, and deliver messages to service endpoints.

Things get more complex when you’re working with technologies like Kubernetes. The number of available endpoint services can vary as the orchestrator adds and removes pods and nodes to manage resources. The unpredictable number of moving parts makes traditional ways of managing messages difficult.

As more at-scale, cloud-native applications have to work with the edge, we need to think about messages differently. At the very least we need new ways of defining the link between messages and endpoints, as there’s no way to be sure that an endpoint address will be the same between calls. Traditional addressing techniques that take advantage of network addresses start to break down.

We need to be able to send those messages in a way that can respond to changes in application topology in real time, and where endpoints are discovered by an alternative to IP addresses.

Introducing NATS

That tool is here now, part of the Cloud Native Computing Foundation’s incubation program. NATS, the Neural Autonomic Transport System, builds on lessons from biology to build a new form of messaging middleware designed to work in modern environments. Written in Go, like Kubernetes, it offers a common messaging server that can be run anywhere, and a set of clients for most common development platforms. Even though NATS’ focus is on linking mobile clients to central servers, its architecture is suitable for any edge-to-core messaging application.

Most current messaging architectures require a 1:1 connection pattern. NATS aims to improve operations by using a M:N connectivity model, a superset of 1:1. This approach allows you to work without the complexities of a modern networking architecture and reduces the need for load balancers and proxies. It offers its own security tools to avoid the overhead of added services.

Key to the operation of NATS is what it calls “subject-based messaging.” This is a variant of the familiar publish-and-subscribe model, with subjects grouped into a hierarchy. The server tracks which clients are subscribed to which subjects, and if there are no subscriptions to a message’s subject, it’s dropped, which saves on resources.

There are memory requirements that come with managing subscriptions, so while they’re technically unlimited, it’s a good idea to scope them in advance (using a. to separate each level in a hierarchy). Each level in a hierarchy is a separate token and can be used with wildcards to fine-tune subscriptions, behaving like a namespace.

Deploying NATS servers

A NATS server can be deployed in many ways, with support for most common OSes. If you’re planning to use it as part of an Azure application, you can choose between Linux and Windows, with x86 and Arm64 builds. You can start small, with the cheapest possible host VM, and scale up as necessary. By taking advantage of NATS’ minimal hardware requirements, starting with one core and 32MB RAM, it’s an economical choice that balances between server and networking performance.

Although NATS is often used to route messages without storing them, it includes a message queue service called JetStream. This provides a shared history across all the NATS servers in a cluster, allowing clients to retrieve messages at any time. This is useful, say, if you’re building a mobile app that needs to be able to synchronize events with a server if it goes offline for any time.

Installation options include a binary or a Docker container. If you prefer, it’s available via the third-party Scoop package manager. Alternatively, you can clone the GitHub repository and build your own install using Go. This approach can be used to embed a NATS server in your own code. The easiest option by far is to use a Docker container to host your server. This allows you to run it isolated from other applications and ensures that you have all the required components in one place.

Once installed you can use NATS’ CLI to manage your server. The latest versions of the NATS CLI replace several different tools, giving you one place to manage your messaging server. Like the server, it’s written in Go, so it can be installed via existing Go tools or using Scoop. This gives you the possibility of quickly hosting a test server on development PCs.

Using NATS in.NET clients

Servers need clients, and NATS has an official.NET client, available from NuGet. It supports both the older.NET Framework via.NET Standard as well as the modern.NET 6.0 and later. It’s important to use the right client version, NATS.Net, as an older, deprecated version is also available.

Once you have a server running, you’re ready to build your first.NET NATS client. Download the NATS.Net package and add references to it in your project. This lets you create a NATS client object, which lets you subscribe to the NATS message stream and then use an asynchronous function to capture data as it’s sent out. The client can be used to publish as well as read, so you only need to install the client once.

The.NET client supports JetStream too, using similar techniques to connect to a subscription. Messages stored on a server are processed in order, ensuring that chronology is preserved, with a network of NATS clients offering eventual consistency. Here the server cluster becomes the source of truth for your application..NET NATS at scale with Aspire.NET support for NATS goes beyond building your own infrastructure, as it’s now part of the Aspire distributed application framework. NATS is managed as a server resource, using a builder statement to create an instance in your application, ready for use. You can use the same tool to work with existing NATS servers by defining a connection string in Aspire.

This adds a simple server without JetStream support. Simply add a WithJetStream statement to your builder to enable it. At the same time, you can define a storage directory outside the NATS container where it will store JetStream data. If you define this as a data volume, it will be available if the NATS container crashes and restarts, enabling basic message resilience. One of Aspire’s more useful features is its built-in health checks, which will test your NATS server regularly to ensure it is running and that clients can connect.

Aspire provides its own packaging for the NATS.Net client, using its own dependency injections to add configurations where necessary. Again, you use its builder feature to add clients and configure message namespaces.

Working with NATS in an Aspire application is much like working with it in any other environment. What’s important is that Aspire offers a way to deploy and configure both servers and clients. This should allow you to focus on the essential logic of your application. Configuration is managed in one place, with the option of using JSON to store connection strings so you can use source control to manage it.

Open source tools such as NATS are key to delivering at-scale, cloud-native applications, so it’s important for.NET Aspire to support them—even when they’re still in incubation.