A self‐contained module that runs independently,
owns its recv/sender channels and shared state,
and processes incoming WS messages according to its routing rule.
It’s main difference from ApiModule is that it does not
require a command-response mechanism and is not intended to be used
as a part of the API, but rather as a lightweight module that can
process messages in a more flexible way.
It is useful for modules that need to handle messages without the overhead of a full API module
and can be used for tasks like logging, monitoring, or simple message transformations.
It is designed to be lightweight and efficient, allowing for quick processing of messages
without the need for a full command-response cycle.
It is also useful for modules that need to handle messages in a more flexible way,
such as forwarding messages to other parts of the system or performing simple transformations.
It is not intended to be used as a part of the API, but rather as a
lightweight module that can process messages in a more flexible way.
A trait for callback functions that can be executed within the context of a module.
This trait is designed to allow modules to define custom behavior that can be executed
when a reconnection event occurs.
Data returned by the rule function of a module.
This trait is used to define the rules that determine whether a message should be processed by a module.
It allows for flexible and reusable rules that can be applied to different modules.
The rules can be implemented as standalone functions or as methods on the module itself.
The rules should be lightweight and efficient, as they will be called for every incoming message.
The rules should not perform any blocking operations and should be designed to be as efficient as possible
to avoid slowing down the message processing pipeline.
The rules can be used to filter messages, transform them, or perform any other necessary operations