@jkarneges about production tips, have you some one? and other little question, I can just scale pushpin horizontally without issues at moment that I whant publish a message to a channel is connection is handle by pushpin-1 and control message is get by pushpin-2
what you do with the received data is up to you. if you want to easily update existing elements on a page when data arrives, you might want to use a UI framework of some kind like angular or react. but this is very outside the scope of pushpin
@jorgecuesta if you have multiple pushpin instances, you need to make sure you publish data to the instances that have listeners. an easy way to handle this is to simply publish to all instances. a more advanced way is to track subscriptions per-instance and publish only to certain instances
it's better to track subscriptions rather than connections. there are two ways to do this: 1) monitor the stats socket for subscription events and store the state somewhere, 2) use a zmq PUB socket for publishing instead of HTTP. the PUB socket automatically figures everything out
right. and for that there are a bunch of ways you could do things. you could integrate with something like redis or rabbit. or make your own broker thing
you can see sourcebroker.py and edgebroker.py in pushpin tools folder for some inspiration
edgebroker lives with each pushpin, connects to the local pushpin sub socket, and also connects out to one or more sourcebrokers
sourcebroker listens for connections from edgebroker and listens for connections from publishers. so publishers send to sourcebroker, which sends to edgebroker (which then sends to pushpin over localhost)
For another data point that works well for us, we went with a model of a slightly more intelligent "sidecar" that's deployed with each pushpin "pod", to use the kubernetes terminology. That sidecar subscribes to one or more redis pub/sub channels and publishes the messages to the adjacent pushpin's port 5561.
This let us remove the discovery problem that you're talking about @jorgecuesta, and publishers just publish to a common redis channel. As our pushpin nodes scale out horizontally, no application-layer things need to know about any changes.
You could obviously swap zmq/rabbitmq/etc for redis.
@acmcelwee you say something like a node/python running with pushpin that handle (each one) the same rabbitmq/redis? Channel to listen about a common message path and push that message on adjacent pushpin instance, so pushpin will try to see is that subscription is handle by him
thanks @acmcelwee and @jkarneges :)
just one last thing some kind of config or setup that could improve to use pushpin in production?