BitGonzo
Here is my current structure:
- scheduler app (Elixir app)
- background worker app x 2 (Elixir app)
- web app x 2 (Phoenix app)
The scheduler, background workers and web apps are completely separate applications (not part of an umbrella app); they could be on different nodes, even in different regions.
However, all of these applications need to speak to my database, and for that I have common ecto schemas.
My question is two-fold:
- would you use a library for the common domain model?
- what is the best way to handle that during development?
For example, in the past I would reference a local copy of the library in order to develop on, but unsure if this is straight-forward in Elixir, or if there are gotchas I need to be aware of (noting that only the web app is a Phoenix app).
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
aseigo
What I have done in this situation is create a mix project that contains the migrations and schemas (and usually some of the common interaction functions, like ones to generate useful changesets) and then use that as a dependency in all the individual projects.
During development, I replace the usual git path to that library in the mix dependency with a local path, e.g. this:
becomes
Then changes during devel to the schemas gets picked up in further calls to
mix compilewithout having to commit, push,mix deps.updateetc. Very handy! Then before committing into the feature branch of the application repo(s), I revert the mix.exs change (git stashis pretty handy here), so that the path version does not polute the app repo.Also Liked
benwilson512
Folks tend to forget you can return
:ignorefrom astart_linkfunction. GenServer — Elixir v1.20.2. If you return:ignorefrom a start link it’ll just get ignored. This means you can have your worker list be a nice full worker list, and then the start_link function of each child can determine whether it should actually start or not.This tactic works great for sort of “feature flag” style workers where they’re all pretty independent. Not so great for tightly coupled workers.
nsweeting
I feel like you might be forcing separation of concerns without reason. If all the apps rely on the same schemas and database - why not just join them into a singular app? If you want some nodes to run certain services, but not others (ie. Your background workers to not run your endpoint) - you can just use env flags to control what is started in your supervision tree.