Proposal: RabbitMQ Node, Live Metrics, or Custom Port Mappings

[NureniJamiu]

Hi @Derssa ! 👋

It was a great experience contributing my first feature to this codebase, and I'd love to continue contributing to the project.

I've been looking over the roadmap and the codebase, and I have identified three potential features that I believe to go well with the project's educational system-design focus. But before I go ahead and open issues for them, I wanted to share them here to confirm if these are features you'd like to see in the codebase and to also ensure they aren't already being worked on by someone else. It would also to be nice to confirm if I can have one of these assigned to me once we decide on the direction.

Here are the three ideas I've drafted:

---

Idea 1: Add a "RabbitMQ" Message Broker Node

The target here is simple. Introduce a message broker node to the canvas palette under a new "Message Brokers" category, allowing users to build and visualize asynchronous event-driven architectures.
My approach to this would be to follow the step-by-step guidelines in docs/adding-a-node.md. It would default to standard ports (5672 for RabbitMQ and 15672 for the management UI) and use a standard official container image, mirroring the setup of the Redis/MongoDB database nodes.

Idea 2: Live Container Resource Metrics (Observability)

The goal here will be to show simple real-time CPU and Memory usage bars inside node inspector modals when the container is running.
My approach to this would be to expose a lightweight GET /api/containers/:id/stats endpoint on the backend querying the Docker daemon's native stats stream (/containers/:id/stats?stream=false). The frontend inspector modals would poll this endpoint periodically to show light resource-usage indicators (paving the way for the "Observability" roadmap item).

Idea 3: Custom Host Port Bindings for Computing Nodes

Here, users would be allowed to expose container ports (e.g. expose an Ubuntu web server's internal port 80 to host port 8080) directly from the UI.
My approach to this would be to extend ContainerManager.createContainer to take optional host-port mappings, and add a simple "Port Mapping" section inside the Ubuntu node UI. Doing this would let users interact with web servers or custom APIs running inside their canvas nodes from their local host browser.

---

If you're open to any of them, please let me know and I'll create the formal issue and start working on the implementation.

Thanks again for building Torollo!

[Derssa]

Go ahead! These are all great ideas. I can't wait to review your PR. 😃

[NureniJamiu]

Thank you. I'll create the formal issues now while I commence work on the implementation.