async-nats

The official async, Tokio-based Rust client for the NATS messaging system

SDK
Cargo
v0.50.0
1,532stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
82/100Excellent
Development Activity68
Maintenance84
Community76
Maturity60
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
81/100Excellent
Architecture86
Code Quality84
Innovation80
Learning Curve75

async-nats is the current, actively-developed Rust client for NATS — a cloud-native publish/subscribe and request/reply messaging system widely used for microservices and distributed systems. It is a full rewrite of the original synchronous nats crate (now deprecated) built from the ground up on Tokio, exposing idiomatic async APIs and leaning on Rust iterators for subscription consumption instead of callback-based patterns.

The client covers the full NATS feature surface: core pub/sub messaging, the JetStream persistence and streaming API (including JetStream Management), the Key-Value Store, and the Object Store, plus TLS via rustls (using rustls-native-certs for OS trust store integration) and NKey/JWT-based authentication. It lives inside the nats.rs workspace repository alongside the deprecated synchronous nats crate and a bundled nats-server test helper crate, but async-nats is unambiguously the client application code should depend on today.

What You Get

  • Async connect/publish/subscribe API built on Tokio, with subscriptions exposed as Rust streams/iterators rather than callbacks
  • Full JetStream client support: stream and consumer management, message acknowledgement, and the JetStream Management API
  • Built-in Key-Value Store and Object Store clients layered on top of JetStream
  • TLS support via rustls with rustls-native-certs OS trust-store integration, plus NKey and JWT-based authentication
  • A NATS service framework (service module) for building request/reply microservices with discovery and stats endpoints

Common Use Cases

  • Building microservices that communicate over NATS core pub/sub or request/reply patterns
  • Persisting and replaying event streams with JetStream for event-driven architectures
  • Using the built-in Key-Value store as a lightweight distributed cache or config store without deploying a separate KV system
  • Streaming large objects between services via the NATS Object Store instead of standing up separate blob storage

Under The Hood

Architecture The crate’s core (async-nats/src/lib.rs, client.rs, connection.rs, connector.rs) implements the NATS wire protocol and connection lifecycle — reconnect handling, TLS negotiation via tls.rs, and authentication via auth.rs/auth_utils.rs/crypto.rs — while higher-level features are organized as sibling modules: jetstream/ for streaming and persistence, service/ for the request/reply microservice framework, plus subject.rs, header.rs, message.rs, and status.rs for protocol primitives. This layered design (transport/connection core, then JetStream and service layers built on top) mirrors the NATS server’s own core-vs-JetStream split, letting users pull in only core messaging if that’s all they need. Tech Stack Rust 2021 edition, minimum Rust 1.88. Built on Tokio (rt, net, sync, time, io-util features) with tokio-rustls/rustls-webpki/rustls-native-certs for TLS, serde/serde_json for JSON codec support, nkeys/nuid for NATS-specific auth and ID generation, and optional tokio-websockets for NATS-over-WebSocket connectivity. thiserror provides structured error types throughout. Code Quality 33 source files under async-nats/src plus 13 integration test files under async-nats/tests, covering JetStream, Key-Value, Object Store, and service-framework behavior against a real NATS server (via the bundled nats-server helper crate). A CLAUDE.md file at the repo root indicates the maintainers actively document AI-agent-facing conventions for the codebase, a signal of engineering process maturity beyond just test coverage. API Design The client leans into Rust idioms deliberately per the README’s stated motivation — connection options are compile-time-checked rather than runtime-validated where possible, and subscriptions are exposed as async iterators/streams so consumers use standard Rust while let Some(msg) = sub.next().await patterns instead of registering callbacks. This makes the JetStream and KV/Object Store APIs feel like natural extensions of core pub/sub rather than bolted-on features.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search