Support Websocket protocol for produce / consume

[yanivbh1]

[mateothegreat]

This is a problem in almost all implementations of WebSockets between a front-end (web app) and the message broker in general and I see huge gains in the user experience and implementation fronts that will give memphis another tool in the toolbox to keep it a first class citizen in the space.

Today, I roll my own WebSocket server and then just use a JWT token to perform authentication and authorization.

Off the top of my head, here are some initial requirements:

Pre MVP requirements

• Support either websocket and polling transports or both.
• Mechanism to programmatically control the lifecycle of the connection, such as termination.
• Hooks on gateway connection and disconnection.
• External integration for authentication and authorization when subscribing based on stationName, consumerName, and consumerGroup.

Post MVP requirements

• Round-robin support for routing the initial handoff between stations.
• Some sort of metadata, or tag, support to handle rounding to specific clients.
• Query string support for connection URI that validates a JWT signature against the configured private key.

I see that as what I would need to be able to invest in ripping out existing architectural patterns to minimize the domain complexity overall. 🙏

• Matthew

[yanivbh1]

That's huge @mateothegreat, definitely will take it under consideration once we will get close to it.

[boskiv]

We are defiantly expecting that feature. Using Websocket protocol for frontend frameworks is must to have. We should able to subscribe on stations and consume events from it with React/Angular frontend code.