Should I refactor to umbrella project?

Questions / Help
1

Hi all,

I’ve never used umbrella projects before, and I’m not sure if it will solve a specific issue that I’m strugelling with.
I currently have an application that’s consist of a phoenix frontend and a background process. The background process requires credentials to operate (google big query). Now, there is no reason for the phoenix part of the project not to work without the background process and the credentials. Even more, I know about devs that wants to help me with my project but strugelling with getting the credentials.
I thought about separating the one app into 3, one will be “core” business logic and persistance layer, one for phoenix, and one for the background process. This way I will be able to create mix tasks to start only the core + phoenix.
Do you think that this use case worth the refactoring hassle?
Are there other obvious solution that I’m missing?

Thank you!
Tom

1 Like
2

Well, in my humble opinion, refactoring to an umbrella project is the best option you have for organization purposes.

But, it’s not the only option if you want just to disable the background project. You can create the mix task to start just the core + phoenix without the need to extract your background processes to a different app under an umbrella.

You would just need to create a flag that determines if the child process on your supervisor will or not get started too.

3

Thanks for the response!

If I can always disable different parts of the supervision tree with flags, I’m not quite sure what are the befefits of umbrella apps (except of reuse, of course).

I think that for now I will keep everything together and add one or more mix tasks for simplify development workflows.