Possible issue with distributed heterogeneous nodes about phoenix_pubsub HOT 4 CLOSED

There are a couple issues going in this case. First, the fastlaning from the channel side, and next the %Phoenix.Socket.Broadcast{} struct that is sent as part of channel broadcasts. Both will cause another node to not be happy receiving a message since the Channel/Socket code is not loaded. It's not as simple as extracting this code out because if we take a step back and look at our system, we will need something sitting between the incoming pubsub messages and our channel client messages. Some ideas around how to better solve this than you starting your own intercepting server(s) that subscribe to topics and relay messages started with this POC PR:
https://github.com/phoenixframework/phoenix_pubsub/pull/34/files

Meanwhile, we have an ongoing effort to rewrite Phoenix.PubSub (https://github.com/phoenixframework/firenest) as a distributed tooling library, part of which handles pubsub. We took the lessons learned here and solved them with a configurable "dispatcher" that can both handle fastlaning and intercepting messages. This would allow each node to handle message delivery differently on each side without an extra process in between.

So the answer today for Phoenix.PubSub is to have a process on the channel side receiving messages and converting those messages into local broadcasts that channel clients understand. This may seem like a lot of work, but it makes sense when you have a remote node broadcasting some data, most likely in a form that's not tailored to consumption by remote browser clients. So we have channel_app <-> elixir_app messages with rich data, and the channel app side converts whatever subset of messages into local channel broadcasts as it receives them. This becomes less work and more efficient in firenest, but it's still a work in progress so expect changes if you hop on board. Hope that helps clear things up!

from phoenix_pubsub.

As a simple fix, could the fastlane handler be configured per client, and not once? That was when my nonphoenix client subscribes, it looks up the fastlane when the message is received, rather than having the sender supply it...

from phoenix_pubsub.

As a simple fix, could the fastlane handler be configured per client, and not once?

That's what we do in firenest :) It's a bigger refactor to make this change on Phoenix.PubSub, especially since we are moving towards firenest for the future

from phoenix_pubsub.

How close is firenest to being mostly usable? I'm writing a course, and although a trivial roll-your-own pubsub is probably 50 loc, I'd really prefer not to reinvent the wheel.

from phoenix_pubsub.