You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The basic MVP of TraderX included a 'quick-and-dirty' WebSocket-friendly messaging system based on NodeJS called SocketIO which allowed a single process to handle server-to-server messaging and client pub-sub and streaming messaging with very little code using native JSON.
This will not scale as we try to add more sophisticated high-frequency flows to the project, and therefore we should look at alternatives which are simple enough to allow minimal learning curves, yet powerful enough to allow for higher frequency messaging.
The goal here is to keep the TraderX process as simple as possible, while allowing elements of it to scale as needed by developers.
Requirements:
This must listen on a port that can be connected to by other TraderX components which require messaging.
There must be a way for web GUIs to subscribe to updates - typically delivered over this messaging system, presumably via websockets. (This can either be the same process, or a separate process)
If the gui/websocket connects from a separate process other than the messaging system, ideally there should be a way for NodeJS (hosting the web gui) to connect to the messaging system and proxy connectivity to the GUI using websockets.
Potential Solutions:
Options include kafka, activeMQ/Artemis, perhaps apache pulsar standalone.
The text was updated successfully, but these errors were encountered:
As of now, the option which seems like the simplest to adopt is to go with Apache Pulsar, in embedded mode, with webSocketServiceEnabled=true to allow a single message bus to supply messaging for both web and server-side components.
Feature Request
Description of Problem:
The basic MVP of TraderX included a 'quick-and-dirty' WebSocket-friendly messaging system based on NodeJS called SocketIO which allowed a single process to handle server-to-server messaging and client pub-sub and streaming messaging with very little code using native JSON.
This will not scale as we try to add more sophisticated high-frequency flows to the project, and therefore we should look at alternatives which are simple enough to allow minimal learning curves, yet powerful enough to allow for higher frequency messaging.
The goal here is to keep the TraderX process as simple as possible, while allowing elements of it to scale as needed by developers.
Requirements:
Potential Solutions:
Options include kafka, activeMQ/Artemis, perhaps apache pulsar standalone.
The text was updated successfully, but these errors were encountered: