It sounds like you’re pretty well sorted on the questions you had, but reading your post I think that I’d recommend not having a separate process for the MsgTransformer, and instead convert that into a plain module that is used by the frontend process. My reasoning is that it sounds like the MsgTransformer process is being used for code organization rather than isolation/resilience (plus adding a process always adds performance overhead). If you haven’t already, I highly recommend reading Saša Jurić excellent blog post on this topic: The Erlangelist - To spawn, or not to spawn?

Children are started in the order you list them. Once one returns from init, the next one starts.

If Frontend depends on it then it should start first. Your second point kind of illustrates that. You could try to detect if the named process is started but you might as well use supervisors to guarantee it.

You are basically pulling the childspec calls from your app into each supervisor with a bit more boilerplate. A supervisor is a behavior of a GenServer, which I map to something like traits in PHP. Since you want to manage dependent processes, it makes sense to group them as a supervisor tree and when your dependency crashes you likely want to re-initialize some state for it.

I think you understand quite a bit but it helps to put theory to practice. You could spike on a throwaway branch and try different strategies or groupings until it “feels right”. You could also look at all the other children your app handles. The docs for supervisors Supervisor — Elixir v1.17.2 has examples and is pretty comprehensive. The DockYard Academy section on supervisors and the drills are a great as well curriculum/reading/supervisors.livemd at main · DockYard-Academy/curriculum · GitHub.

I typically group processes by strategy and dependencies. If you need to start a collection of processes together then I would place them under a dedicated supervisor. You may want the :one_for_all so that a restart in one restarts all of them. You can use module based supervisors and either split the responsibility or just tack it on. I would personally only split when the friction required it.

You’ve described your supervision tree perfectly here. The app starts only ModelManager, that supervises FileServer and Frontend where frontend is also a supervisor for MsgTransformer.

Hey, thanks for this! Can I ask a few follow-up questions?

• I’m kinda hesitant to have ModelManager supervise the frontend (for instance) because these are not really logically connected: It’s thinkable that a variant of the app would run without the frontend (and instead with a web frontend or GUI, for instance, or as a sync server). Any alternatives come up here?
• How do I make sure the ModelManager is started before the frontend etc.? As in, what code do I use? I feel a bit dumb here, honestly, as if there’s some command I just don’t know?
• Oh, and can something be both a GenServer and a Supervisor at the same time? (possible I still have my OOP goggles on a bit too tightly here, maybe it’s just fine?)