bruno_louvem
Approach to microservice dependecies in umbrella project
Greetings, everyone! In an attempt to get to know about the best practices
when dealing with umbrella application projects, I’d like to share an
architecture-related dilemma that my team and I have recently faced.
Our goal was to structure our umbrella apps in a microservices-like fashion,
with a single underlying database storage. At first, each app would have their
own schema, model and domain definitions, but this eventually led to circular
dependency issues when inter-app references began to pop up.
To illustrate, we have an “Auth” app, with entities associated with
authentication, and a “Profile” app, to store additional personal info (phone
number, profile picture, etc.). We could not figure out how to build a
“belongs_to” <-> “has_one” relationship between entities from these two apps
since each one would have to depend on the other to be able to reference the
schema module contained in the other app.
After a bit of research, we stumbled upon a proposition for an architecture
containing an additional umbrella app (say “Datasets”), dedicated to interfacing with the database.
This way, every other app would have it as a dependency, and all the schema
definitions would be stored within this app, organized according to namespaces
such as Datasets.Auth.User, Datasets.Profile.Account…
Given that this system wouldn’t need to rely on heavy decoupling of its apps,
are there any anti-patterns in this approach that could cause trouble in the
long run?
Most Liked
arkgil
IMO if all your services share the data store then they are one, single service. If you need an extra application for handling database schemas, which all other apps depend on, to me that’s an indication that those apps shouldn’t be thought of as distinct services. You could as well use a non-umbrella project with all schemas namespaced under Datasets. module.
subetei
Couldn’t find a lot of good examples of this myself when researching this. Sharing what’s worked for me the last few months… it’s similar to your proposal and hasn’t caused an issue yet.
Umbrella - All deployable services
- Web
- Api
- Process server
Data App - own individual repo/app
Search App - own individual repo/app
Didn’t put the others in an umbrella, each lib outside of umbrella is individual atm. And yep it’s easy in Phoenix for example to replace in the application tree your ecto source so my access looks like DataService.QueryPost.get_something… The search works the same and any of my umbrella apps can opt in to either service.
I could see the use of putting the extra shared libs in an umbrella since its easier to add new projects without temptation to cram things into data. Interested what more experienced elixir folk say but can say after many features and about 10 big deployments this still holds up
AstonJ
I’m extremely interested in the Replaceable Component Architecture and I highly recommend PragDave’s new online course:
It has sparked some really interesting discussions on the forum and I think every Elixir developer would find that course invaluable - even if just to see how other experienced developers are using Elixir. I’m personally really excited by what he’s a proponent of and can’t wait for his next course 
With regards to your question, I actually emailed Dave asking if he would go into some of that in his next course… hopefully he will (he doesn’t use Ecto in the current course and I’d personally like to see how persisted and more closely related data is dealt with in his approach).
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Courses that'll move you from confusion to "Aha, now I get it!"