Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: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.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_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.