I simply wish the best for Elixir and Phoenix.
@josevalim I suggested in a separate thread for the Elixir and Phoenix team to create samples that can help people like us to grasp these concepts. That is one thing that helps languages/frameworks like aspnetcore, angular2 etc.
If there are samples backing all the explanations you and @chrismccord have given, you will have to talk less.
Thanks for the upcoming RC. Any idea the release date?
Hi, I’m new just coming from Rails, but I saw the video talking about Phoenix 1.3 and was amazed about the new contexts concept. I am eager to build a little application with this.
One thing related I am confused about is where I should put the intermediate table. For instance, here I want to create a chat application, I have a User and Room. It should be a N-M association.
app
|--account/
| |--user.ex
|--account.ex
|
|--services/
| |--room.ex
|-- services.ex
And now I’m wondering where I should put my room_users.ex. I want to separate User and Room because User should be used in many other places. What should I do?
Well, depends on how you want to approach it.
The first approach I would see is to have tables namespaced by context with no relations cross-contexts schemas. So you would have two different tables for users - one in the services context and another in the account context. The tricky part is to coordinate changes between then, which you could do using transactions - again, passing through all contexts that have the user schema for example if you want to change the user. The other way is to create a small GenServer module, where you would do a simple PubSub registration/listening and, everytime one of your users tables are changed it should broadcast a message with relevant information that will be captured by the other PubSub GenServers, so it can be propagated into their own versions of users.
The first approach albeit simple, when you need to scale into microservices your monolith will force you towards the second approach and you’ll have lots of pain because you coupled your cross-contexts relations in the same app. The second approach is more decoupled and, as I stated before, can be moved towards its own service, separated database whatsoever without you caring much of what’s going on.
It’s either a mixture of personal taste and what you’ll need. Do you think you’ll need to scale to millions of users? If yes, then, I would go second approach. If not, well, the first one is cheap and does the job as well.
I think your approach is pretty well tied to the Rails way of thinking here. What you’re trending towards is tightly coupled contexts, which is worse than just building a monolith.
For example, why are you storing them in the database? A user being in a room is inherently session-based—this is where you should maybe reach for a GenServer instead of writing to the database. If you want to store a list of rooms the user should be automatically logged into when returning, maybe consider a context for user preferences. Then a layer higher up can orchestrate between the preferences and the room subscriptions.
Secondly, why does the room need to know anything about the user, like its account information? Would simply telling it which IDs or nicks that are currently in the room suffice for it to do its job?
Try to take a step back and ask why it seems hard when you run into questions like this. Generally I find that trying to puzzle where a particular notion goes is a signal to me that I’ve gotten a boundary wrong.
I really like the second approach. I personally I am struggling to understand the GenServer stuff. I don’t know if you can write a sample on how PubSub can be achieved.
I read about bounded context yesterday and I was wondering the best way to implement it in Phoenix.
Thanks for your response
@smithaitufe I suggest you create a small elixir application and play with Supervisors, GenServers, GenStages, etc… 
I don’t know if you can write a sample on how PubSub can be achieved.
I’m not sure if that’s what you need, but have you checked Registry module in elixir? It has a note about how to use it as a local pub/sub system in the docs [0].
You can put it in a separate app under an umbrella and let processes from other apps subscribe to certain topics in it.
apps/pubsub/lib/pubsub.ex
defmodule Test.PubSub do
def start_link do
Registry.start_link(:duplicate, __MODULE__)
end
def subscribe(topic) do
Registry.register(__MODULE__, topic, [])
end
def unsubscribe(topic) do
Registry.unregister(__MODULE__, topic)
end
def publish(topic, message) do
Registry.dispatch(__MODULE__, topic, fn entries ->
for {pid, _value} <- entries, do: send(pid, message)
end)
end
end
apps/pubsub/lib/pubsub/application.ex
defmodule Test.PubSub.Application do
@moduledoc false
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
children = [
supervisor(Test.PubSub, [])
]
opts = [strategy: :one_for_one, name: Test.PubSub.Supervisor]
Supervisor.start_link(children, opts)
end
end
To subscribe for updates in user app in a phoenix channel you would do something like
defmodule Test.Web.UserChannel do
use Test.Web, :channel
def join("user:" <> name = topic, _params, socket) do
{:ok, _owner_pid} = Test.PubSub.subscribe(topic) # subscribe to updates in "user:#{name}"
{:ok, socket}
end
# and handle these updates
def handle_info(:sacked, socket) do
broadcast! socket, "sacked", %{}
{:noreply, socket}
end
end
Somewhere in the user app you would publish the message :sacked in case of a ban
...
Test.PubSub.publish("user:idiot", :sacked)
...
These are basically the examples from the Registry docs, and there are some more about other possible uses for it.
Note however that this pub/sub implementation is local. And if you are using phoenix, you might want to pick Phoenix.PubSub [1] instead which is not local, so that for the example above (with channels) you would probably use phoenix’s pub/sub library.
[0] https://hexdocs.pm/elixir/master/Registry.html#module-using-as-a-pubsub
[1] Phoenix.PubSub — Phoenix.PubSub v2.2.0
Using Phoenix’s PubSub is better for this because it can broadcast messages between nodes, either using Erlang’s pg module, Redis or RabbitMQ. I think there’s a Kafka as well, but I’m not sure.
@imetallica, @karmajunkie, thanks for your replies. I guess I need to do more exercise on Elixir/Phoenix, including PubSubs. thanks again!