Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more robust messaging capabilities (e.g. ActiveMQ, etc) #35

Open
DovOps opened this issue Sep 8, 2023 · 1 comment
Open

Add more robust messaging capabilities (e.g. ActiveMQ, etc) #35

DovOps opened this issue Sep 8, 2023 · 1 comment
Labels
good first issue Good for newcomers

Comments

@DovOps
Copy link
Contributor

DovOps commented Sep 8, 2023

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:

  • 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.

@DovOps
Copy link
Contributor Author

DovOps commented Sep 27, 2023

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.

Spring Boot has a good pulsar-starter reference, with annotation-driven custom message type bindings which work on top of JSON (which could work until we shift to a binary format)
https://docs.spring.io/spring-pulsar/docs/current-SNAPSHOT/reference/html/#_message_production

Pulsar runs in standalone mode for easy local development and self-contained environment.
https://pulsar.apache.org/docs/3.1.x/getting-started-standalone/

Websockets can be enabled via a config option:
https://pulsar.apache.org/docs/3.1.x/client-libraries-websocket/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants