BitGonzo
Sharing schemas across applications?
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).
Marked As Solved
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:
{:my_database, git: "git@git.somewhere.com:path/to/my_database"}
becomes
{:my_database, path: "../my_database"}
Then changes during devel to the schemas gets picked up in further calls to mix compile without having to commit, push, mix deps.update etc. Very handy! Then before committing into the feature branch of the application repo(s), I revert the mix.exs change (git stash is pretty handy here), so that the path version does not polute the app repo.
Also Liked
benwilson512
Folks tend to forget you can return :ignore from a start_link function. GenServer — Elixir v1.20.2. If you return :ignore from 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.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








