Each application should have its own supervision tree. Then, if the phoenix app depends on the supervisor app, you need to list the supervisor app as a dependency in your mix.exs file. If you are using umbrella, this is a matter of adding {:supervisor, in_umbrella: true} to deps. By doing this, Elixir will automatically start the supervisor app and its supervision tree before it starts the Phoenix one.

I think it would be better if you actually use the shared configuration suggestion for umbrellas. Run mix phx.new foo --umbrella and you will see how it is designed. But in a nutshell every child application has a line in their mix.exs that points to the umbrella config files. As I said, the goal of the umbrella is to share deps and config, so if you keep them in separate applications, it gives the impression they are not shared while they do. Unifying everything in the config folders of the umbrella will be clearer.

Just running mix phx.server should start everything, the phoenix server and your game state (assuming everything is wired via your application’s supervisor properly). Or if you want the console then iex -S mix phx.server.

I personally don’t like umbrella apps, I prefer dependencies. However, why not just pass in the main Ecto Repo through everything, and if you start Ecto before starting the websocket server then there is no serialization issue.

As for umbrella’s, perhaps others could talk about those, I find them horribly messy, always have since my old erlang days so I’m probably biased. ^.^;

Is this the proper relationship? Shouldn’t the phoenix.channel start the supervisor because it needs it to work and not the opposite?

The default configuration for umbrellas is to share all configuration from all projects. I am assuming that you have opted-out from this behaviour explicitly? You could use import_config on both apps and make them import the ecto configuration from state_app but given that you are running into issues, asking if using umbrellas is the way to go is indeed wise.

Umbrellas were designed for apps that share the same dependencies and configuration. So if you want to configure some apps differently or you want to update a certain dependency for one app or not the other, then it is indeed best to drop them.

The good news is that you can still keep a very similar structure. You can keep all projects in the same repository and use :path instead of :in_umbrella for your deps. The main difference is that you are explicitly saying those things are not coupled at the config and dependencies level, so other approaches may feel more natural.

Nothing wrong with having apps called data (structures and integrations with DBs and various storage backends), domain (or something similar that expresses business logic), then probably web and api that are the server-side rendering app, JSON app etc. etc.

Used that several times, it provides a very neat separation of concerns as long as you do explicit dependency management ({my_app, in_umbrella: true}).

Using path dependencies in this case is a very leaky and lame way of doing it. What if I have 5 of my apps in totally different directories both in dev and prod?