Why?

Authentication / Security

One way to deal with authentication and security is to keep it like it is generally done now with a REST API in front of it. This way, it can still utilize common security practices like token based authentication and HTTPS security. Most brokers are not built with public facing APIs in mind, so they don't handle this very well and are all quite different in how they handle it (eg: MQTT supports plain text username/password or you could get more technical and use X.509 certificates on the TLS handshake, but are you really going to make your users remember an X.509 cert?).

AsyncAPI has some things in the spec, but seems mostly http related: https://www.asyncapi.com/docs/specifications/2.0.0-rc1/#securitySchemeObject

Browser support

Additionally, most of these brokers don't have good browser client support. Nats requires a websockets to tcp proxy/relay anyways. Only one MQTT broker, HiveMQ, that I could find has a browser capable client.

Solution

We could define a common input and output wrapper format for all events along these lines:

AsyncAPI servers.protocol: "rest?"

To publish:

POST /event_endpoint Authorization: Bearer ABC { "channel": "abc", "message/payload": [ASYNCAPI SPEC message], }

To subscribe via websockets:

GET wss://{servers.URL} HTTP/1.1 Origin: http://example.com Authorization: Bearer ABC Connection: Upgrade Host: {servers.URL} Upgrade: websocket

First message sent to subscribe: { "command": "subscribe", "channel": "abc", }

Then receives all messages on "abc" channel. This could be a direct proxy to the underlying broker, very thin.

Could have similar websocket scheme for publishing too.

treeder / async-toy-store