Here I'm proposing an addition to the configuration options for Phoenix.PubSub.Redis to make it possible to specify the Redis channel for pubsub directly.
Motivation
Currently the Redis channel name is derived from the adapter name, e.g. "phx:Elixir.MyApp.PubSub.Adapter". This is not entirely obvious and could pose a challenge for some applications:
When using Phoenix.PubSub with Redis to communicate between separate Elixir app/umbrella apps, the current design makes it necessary for the registered name for the pubsub process to be the same across all apps. This is a particular challenge in umbrella apps where it might be desirable to have separate pubsub processes per app.
It is possible to inadvertently change the channel used by modifying the module name defined for Phoenix.PubSub. In some situations this could cause unexpected behaviour, especially if the pubsub channel is used in a distributed environment.
The coupling of the adaptor name to the Redis channel means other systems participating in the channel need to adopt the internal naming of an Elixir app
Personally I ran into this with an umbrella app where we want to have separate pubsub processes per app to avoid coupling.
Changes
Changes are straight forward, basically just accepting an optional redis_channel configuration argument and stashing that in ETS. The implementation defaults to the current channel naming where no channel name is specified, so as to be backward compatible.
Here I'm proposing an addition to the configuration options for
Phoenix.PubSub.Redisto make it possible to specify the Redis channel for pubsub directly.Motivation
Currently the Redis channel name is derived from the adapter name, e.g.
"phx:Elixir.MyApp.PubSub.Adapter". This is not entirely obvious and could pose a challenge for some applications:Phoenix.PubSubwith Redis to communicate between separate Elixir app/umbrella apps, the current design makes it necessary for the registered name for the pubsub process to be the same across all apps. This is a particular challenge in umbrella apps where it might be desirable to have separate pubsub processes per app.Phoenix.PubSub. In some situations this could cause unexpected behaviour, especially if the pubsub channel is used in a distributed environment.Personally I ran into this with an umbrella app where we want to have separate pubsub processes per app to avoid coupling.
Changes
Changes are straight forward, basically just accepting an optional
redis_channelconfiguration argument and stashing that in ETS. The implementation defaults to the current channel naming where no channel name is specified, so as to be backward compatible.