Asyngular is a new lightweight real-time framework which is protocol-compatible with SocketCluster; this means that existing SocketCluster clients should be compatible with both SocketCluster and Asyngular on the back end. For JavaScript, however, it is recommended to use the default asyngular-client to make the most of the new async/await flow.

Asyngular was originally meant to be version 15 of SocketCluster but the changes to the API ended up being significant enough that I decided to keep both libraries as separate projects.

The name “Asyngular” encapsulates the following ideas:

Asynchronous; because the async/await feature of JavaScript is at the core of its design.

Asyngular is pronounced “A-singular” and is a play on word to mean “not singular”; because it was designed to run at scale in a cluster alongside other Asyngular instances. Asyngular will ship with all necessary Kubernetes .yaml files and will provide CLI tooling so that it can be easily deployed and scaled on any standard Kubernetes cluster.

It sounds a bit like “Angular” because it aims to have the same kind of impact on the way developers write JavaScript on the back end as the Angular framework had on the front end; to encourage more declarative/reactive logic.

Asyngular introduces some radical new ideas and changes to SocketCluster, this was done to deliver the following benefits:

Application code written on top of Asyngular is reactive and should be easier to follow; because there is no need to nest event listener callbacks, code can run sequentially from top to bottom. Everything can now be produced and consumed using async/await.

Message/RPC order can be guaranteed even for advanced scenarios. By default, all messages/RPCs arrive in the order that they were sent by the client even if asynchronous calls are made inside middleware or inside event loops on the server. Asyngular introduces the concepts of data streams and back pressure.

API explicitly separates RPC events which expect a response (invoke) from message events which do not expect a response (transmit).

API makes a clear distinction between one-off events and recurring events (e.g. let event = await socket.listener(eventName).once() vs for await (let event of socket.listener(eventName)) { /*...*/ } ) — This helps to avoid accidental double-binding of listeners (which was a common issue for new users of SocketCluster).

vs ) — This helps to avoid accidental double-binding of listeners (which was a common issue for new users of SocketCluster). API helps to prevent memory leaks on both the client and server side. There is no need to explicitly destroy() channels or sockets in Asyngular; they will be automatically cleaned up by the garbage collector once they are no longer referenced/used in the code.

channels or sockets in Asyngular; they will be automatically cleaned up by the garbage collector once they are no longer referenced/used in the code. Message and event streams can be easily throttled, filtered and combined in complex ways (e.g. using async generators).

Architecture has been simplified to focus purely on horizontal scalability; each Asyngular instance runs in a single process and is attached directly to a Node.js HTTP server. Asyngular can scale horizontally using AGC (alternative to SCC). The Kubernetes CLI for AGC will soon be bundled into the main asyngular CLI from npm. Use asyngular --help for list of Kubernetes shortcut commands.

To get started with Asyngular, please read the getting started guide.

More documentation will be coming soon.