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
Food for thought related to this: in my application I'm using aiohttp as the HTTP server for the main application providing a REST API. I then expose real-time updates via MQTT over websockets.
aiohttp supports creation and hosting of websockets. Right now for the user to access MQTT I have three choices:
bind amqtt server to a separate port, expose that via the firewall and have my application direct the user to the new port (fine for development, not sure about this for production use though)
bind amqtt server to a separate private port, configure my application's front-end reverse proxy (nginx) to also forward that second port to some URI namespace.
bind amqtt server to a separate private port, configure some sort of reverse proxy within aiohttp to forward the MQTT/websocket traffic to amqtt.
I'm wondering if that ListenerType enumeration shouldn't have a plugin option. This would require the user write a plug-in that implements the same interface as the tcp and ws listener types. Thus, in my application, I could implement a plug-in that creates a websocket using aiohttp calls and binds it to a path in my server's namespace. I'm thinking in this situation, things like the bind option become optional since bind makes no sense when you're not actually binding to a network socket directly.
Anyway, probably this is in the scope of a second related pull-request.
A native approach that avoids the need to bind an additional port would be vastly superior, but as mentioned, let's nut out a game-plan first before we start hacking code. :-)
Food for thought related to this: in my application I'm using
aiohttp
as the HTTP server for the main application providing a REST API. I then expose real-time updates via MQTT over websockets.aiohttp
supports creation and hosting of websockets. Right now for the user to access MQTT I have three choices:amqtt
server to a separate port, expose that via the firewall and have my application direct the user to the new port (fine for development, not sure about this for production use though)amqtt
server to a separate private port, configure my application's front-end reverse proxy (nginx
) to also forward that second port to some URI namespace.amqtt
server to a separate private port, configure some sort of reverse proxy withinaiohttp
to forward the MQTT/websocket traffic toamqtt
.I'm wondering if that
ListenerType
enumeration shouldn't have aplugin
option. This would require the user write a plug-in that implements the same interface as thetcp
andws
listener types. Thus, in my application, I could implement a plug-in that creates a websocket usingaiohttp
calls and binds it to a path in my server's namespace. I'm thinking in this situation, things like thebind
option become optional sincebind
makes no sense when you're not actually binding to a network socket directly.Anyway, probably this is in the scope of a second related pull-request.
Originally posted by @sjlongland in #72 (comment)
The text was updated successfully, but these errors were encountered: