hxgdzyuyi
I’ve been exploring Phoenix.Context recently and noticed that many projects seem to structure it differently.
Let’s say we have a context called Catalog, which includes two sub-schemas: Product and Category.
Following the typical approach:
catalog.exshould contain the CRUD operations and business logic for bothProductandCategory.catalog/product.exshould contain the schema definition and changeset logic forProduct.
However, when the CRUD logic becomes extensive, catalog.ex grows too long, and you might need to split it up. At that point, it feels like the community has all sorts of ways to handle it—there’s no real standard…
My current idea is to structure it like this:
- catalog/products.ex
- catalog/products/product.ex
- catalog/categories.ex
- catalog/categories/category.ex
- catalog.ex
But the module names feel quite long… it’s like having contexts within contexts.
How do you all usually handle this?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
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
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
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!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tomkonidas
Why not just:
If you ever see catalog getting really big with a lot of product/category stuff maybe then think about extracting that, but this probably goes a long way.
al2o3cr
“Too long” in what sense? Understanding that will help understand what solutions can help.
FWIW, I find that lengthy Elixir modules are much less of a concern than lengthy classes in OOP languages - mainly because there’s no “shared state”, so modifying one function is much less likely to cause unexpected changes to the behavior of other functions.
sodapopcan
I make “subcontexts” and
defdelegatein the root if I feel they have gotten too big.