I’m working on a library which dynamically launches one or more websocket and HTTP connections, and I’m wanting to know how I should organize the library for dependent projects’ supervision tree.
My plan is to define a DynamicSupervisor and a Registry in the library for dependent projects to supervise, but for projects which define their own registry, this would mean there’s more than one registry running. Will that matter? Do I need to include a way to override the default registry in the library, and if so, is using Mix config the correct approach?
If you want to allow to have multiple applications using your library independently, then yes.
No, as it will be once per application (library), not per call.
If you want to check out how to define such supervisor and processes in IMHO the best possible way, then check out Ecto.Repo. It is quite popular Elixir library ( ) that does it right.
Okay, so I’m working on understanding Ecto and Registry, and I admit that I don’t fully understand what you meant in this answer:
Per call to _____?
I see that Ecto doesn’t use Elixir’s native Registry. Ecto.Repo.Registry appears to be a simplified alternative to Registry, and since most of the code in Registry seems to be related to partitions, I get the sense that Ecto didn’t need this. Am I on the right track?
One thing to keep in mind when looking at older tools like ecto (started pre elixir 1.0) or phoenix is that it’s possible that core tools were introduced after the library specific ones. Afaik Registry was extracted from phoenix_pubsub; DynamicSupervisor was only introduced in elixir 1.6 to separate the :simple_one_for_one strategy from the others, because there were a bunch of different semantics applicable to just this one strategy. Libraries are sometimes not updated to keep compatibility and not breaking things in case of slight differences between implementations.
So just because you see some code in a library doesn’t necessarily mean it would be coded exactly like that today.
) that does it right.
