cvh23
Best practice for directory structure of a larger application?
Hey,
I am very new to the Elixir world, but doing software development for many years. The Elixir ecosystem looks very promising to me. Currently I am not sure how to structure a larger application in an optimal way. Let’s say I want to create a web shop application named “shop”, which is an API only (REST or GraphQL) application. I would structure it this way (disregarded Elixir):
- shop
- customers
- payment
- paypal
- stripe
:
- communication
:
.
With Elixir (Phoenix) it would be?
- shop
- lib
- shop
- customers
- payment
- paypal
- stripe
- communication
:
- shop_web (all the web/api stuff)
:
- shop
- lib
But what about an Elixir structure like this:
- shop
- lib
- customers
- payment
- communication
- api (all the web/api stuff)
:
- lib
That would be more “natural” to me (for an API only application). Otherwise I would have repeated “shop” and all the code is split more or less in two main directories: “shop” and “shop_web”
Another question: Is it uncommon to have the application name in the module identifier/path? So it should not be “Shop.Payment.Paypal”, but just “Payment.Paypal”. Right?
How should the Ecto repo modules be named? “Payment.Paypal.Repo”? Or “Payment.Paypal.DB”? Should the Repo be seperated from related business logic?
Sorry for mixing the topics a little bit, but for me it’s somehow connected ![]()
Most Liked
atomkirk
I’ve worked on a number of big Phoenix/Elixir applications. I led the development of a big one (200k+ lines) over 4 years. We did it both ways, the way phoenix boilerplate does it for about 2 years, and then we reorganized it. The main thing we learned was to organize your project around features, not functionality. Why? Because which is more common? working on all your tests at the same time? or all your controllers, views, or graphql code at the same time? Or, working on a particular feature? Sometimes you do refactor something across an entire category of functionality, but WAY more often you or someone maintaining your code is working within a feature/resource/group of resources. So here’s how we did it, and we never ever looked back. It it insanely amazing and other people who have worked on our project have commented on how much easier it is to work on a feature and find all the relevant modules they need.
lib/
invoices/
controller_tests/
index_test.exs
create_test.exs
update_test.exs
delete_test.exs
controller.ex
view.ex
view_test.exs
schema.ex
schema_test.exs
jobs/
send_invoices.ex
send_invoices_test.exs
payments/
controller_tests/…
schema.ex
…
customers/
…
We tore a page from golang and we put the tests right by the modules they test. This is so great. Why do we do all the work to build a mirror of our project dir in the test? Tests are code, they are part of our app. This also makes modules that are not tested stand out like a sore thumb. Need to update a module and the test? They are right by each other!
Anyway, I was stuck in analysis paralysis about this, asked the elixir community in slack if I should do this, they all advised against this, but this project has had this structure for 2 years now and I will be doing all projects like this in all languages/frameworks from now on. It is nonsense to organize your project by functionality (controller/view/etc) rather than feature/type/resource. I don’t know rails why ever sent us down that route.
Lastly, when you want to split it up into umbrella apps or microservices, this directly structure is exactly how you’ll want t do it, you’ll just copy the directory wholesale into another app/service/etc. This organization very very much helps facilitate a domain driven design mindset.
I highly highly recommend this ![]()
hlx
One question first, is this for fun or profit?
Fun
Just experiment, take a look at the source code from changelog.com and hex.pm (search on github) and build what you think works for you and post it here for others to look at and help you with. It’s very easy to refactor in Elixir and you’ll learn a ton in the process.
Profit
Just build it with the default settings and ship it. No matter how you structure your app, if you don’t ship it it does not matter.
atomkirk
ultimately, because of how elixir modules don’t care about file location, elixir projects are extremely easy to re-organize. took me 2 hours to totally reorganize our project. So, just do whatever you like and if you realize later you want to do it another way, its super easy to change.
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









