Presently, to my knowledge, there's no way to connect to specific containers of a multi-container Meteor application. The API provides a DDP.connect(url) function but this only connects to a single container of a multi-container Meteor application. The same way visiting an app by URL only connects to a single container.
In a micro-services architecture, It would be helpful for us if Meteor implemented a non-database-bound mechanism to connect and/or message specific containers (or at the very least all containers) simply using DDP. Something like a DDP.connect(url, container) where container is a specific container or an "all" flag. Or possibly DDP.connect(url?_g_container=<container_id>).
This would take advantage of Meteor's existing DDP protocol and would not require implementing hacky database flag work-arounds (that so many packages use) that then rely on database reactivity to do something that may not involve anything from the database. This would let one micro-service call Meteor Methods on specific containers (or all containers) of other micro-services of an advanced micro-service Meteor application structure - where each micro-service may have multiple containers.
Currently there's several packages that implement direct DDP messaging (e.g. streamy or meteor-custom-protocol) but, like DDP.connect() they all assume single-container applications. And don't take into account sending a message to all or specific containers of an app.
One seemingly simple solution would be to update Galaxy to allow access to the current container ids and then we could pass them as query vars to the URL of DDP.connect(url) similar to how you can connect directly to a container using the buttons in the UI of Galaxy (e.g. https://some.app.com/?_g_container_=<container_id>&_g_debug_=true). I haven't tried to see if this works with DDP.connect(url) but the problem before I try that seems to be discovering those container ids and then keeping track of them in a system where they could change at any moment. As Galaxy does a lot of self-replacing of containers. Outside of Galaxy would be a more involved solution I assume.
Our use-case is having an action in one micro-service (e.g. an admin tool) send a message to all containers of another micro-service (e.g. a high-user-count end-user app with lots of containers) to update all of its caches, or dump caches, or <insert server task here>, etc.
Presently we rely on redis-oplog's use of Redis to be a 3rd party universal messenger to send messages from one service to another with a lot of app-level logic to divvy out the messages to the right containers, etc. The more we do this the more it seems like overkill and adds lag time, unneeded complexity, additional points of failure, etc.
Presently, to my knowledge, there's no way to connect to specific containers of a multi-container Meteor application. The API provides a DDP.connect(url) function but this only connects to a single container of a multi-container Meteor application. The same way visiting an app by URL only connects to a single container.
In a micro-services architecture, It would be helpful for us if Meteor implemented a non-database-bound mechanism to connect and/or message specific containers (or at the very least all containers) simply using DDP. Something like a
DDP.connect(url, container)wherecontaineris a specific container or an"all"flag. Or possiblyDDP.connect(url?_g_container=<container_id>).This would take advantage of Meteor's existing DDP protocol and would not require implementing hacky database flag work-arounds (that so many packages use) that then rely on database reactivity to do something that may not involve anything from the database. This would let one micro-service call Meteor Methods on specific containers (or all containers) of other micro-services of an advanced micro-service Meteor application structure - where each micro-service may have multiple containers.
Currently there's several packages that implement direct DDP messaging (e.g. streamy or meteor-custom-protocol) but, like
DDP.connect()they all assume single-container applications. And don't take into account sending a message to all or specific containers of an app.One seemingly simple solution would be to update Galaxy to allow access to the current container ids and then we could pass them as query vars to the URL of
DDP.connect(url)similar to how you can connect directly to a container using the buttons in the UI of Galaxy (e.g.https://some.app.com/?_g_container_=<container_id>&_g_debug_=true). I haven't tried to see if this works withDDP.connect(url)but the problem before I try that seems to be discovering those container ids and then keeping track of them in a system where they could change at any moment. As Galaxy does a lot of self-replacing of containers. Outside of Galaxy would be a more involved solution I assume.Our use-case is having an action in one micro-service (e.g. an admin tool) send a message to all containers of another micro-service (e.g. a high-user-count end-user app with lots of containers) to update all of its caches, or dump caches, or
<insert server task here>, etc.Presently we rely on redis-oplog's use of Redis to be a 3rd party universal messenger to send messages from one service to another with a lot of app-level logic to divvy out the messages to the right containers, etc. The more we do this the more it seems like overkill and adds lag time, unneeded complexity, additional points of failure, etc.