This is correct. They would be different clusters (not in same deployment) and would have no relationship other than the HTTP push API exposed by PushEx.
Your backend sends HTTP requests to /api/push. Your frontend connects to PushEx channels/topics and receives the data through it.
I highly recommend this deployment style if you are wanting things to work out-of-the-box.
The biggest benefit of clustering is the resilience of the system. The most basic example is doing a rolling deployment. With a cluster, you can deploy one server, the next, etc. in a chain. In that case, your app would remain up and available. The users would receive a disconnection but it’s not the end of the world.
If you don’t have clustering and deploy to your one server, you will have guaranteed downtime. It’s worth stating that clustering for a WebSocket app like PushEx is a must if there are multiple servers. The Real-Time Phoenix book goes into this in the deployment section (ending chapters). If server A receives a push API call in its controller, it needs to PubSub.broadcast to other servers. That requires either direct clustering or Phoenix’s redis module that simulates clustering.
The reason I built PushEx is because there’s a bit more to a production system than just the API setup. I made sure to include everything that we used at Salesloft (past employer that I built PushEx for) to give high resilience and operational insight.
