UE Streams Integrations

The pages of this section will provide example and how-tos to connect an open source NATS client to UE Streams. There are several compatible clients available from the NATS community, but we recommend the following for the access to streams and subjects.

UE Auth supports C UE Auth supports C# UE Auth supports C++ UE Auth supports Node JS UE Auth supports Deno UE Auth supports Go Lang UE Auth supports Java UE Auth supports Python UE Auth supports Ruby UE Auth supports Rust UE Auth supports PHP



This is the server DNS for clients to connect to UE Streams.


Examples are in Node.js

Most of the examples are currently in JavaScript. We will work on additional stack examples as well. Nevertheless, most of the clients implement connections and interaction with the streams using the same APIs and approaches so these examples should get you started.

Whats are Subject and Streams?

UE Streams implements data streaming and queuing using the NATS approach of subjects and streams.


Subjects are data pipes where messages are only received if someone is listening to the transmission. These are considered "at-most-once" delivery systems.


Streams are a wrapper around subjects that provide persistence for the data moving through the pipe and allow consumers to receive the data at a later time after transmission. Streams are considered "at-least-once" delivery systems.

Pros and Cons

Streams and subjects are complimentary approaches to event messaging. There are pros and cons to using one approach over the other.


Simpler Setup and configurationLess resilient to system outage
Faster implementationsLess suitable for cross solution integrations
Bi-directional request/responseDifficult to debug issues with data
Load balanced queue groupsNot suitable for data that requires audit of transmission
Less of a security risk in terms of message transmission because subscribers cannot access past messages


Highly resilient for enterprise topologies and use casesMore complex in terms of setup and configuration
Data replication for additional resiliencySlower implementation
Maintains queue group featuresPermissions associated are more complex
Maintains bi-directional data featuresRequires an architecture that is idempotent on the consuming side
More suitable for cross-solution enterprise integrationHigher security risk associated to message transmission because consumers can access past data
Easier to debug issues with data
Message queue is auditable during retention period