Anyone have tips for code organization?

I’m new to elixir, and I’m finding that I often have files have many responsibilities, which I’m not fond of. One frequent occurrence of this I’m seeing is the context files in a phoenix project. If you have many different schemas under that context, you end up having a ton of boilerplate like create_user, create_account, create_admin right next to each other. I really don’t like this and I could see this growing out of control very quickly in a project of consequence. I can’t open up modules for modification in more than one file, as things are overwritten. I’m at a loss at how to deal with this and in my opinion it’s a big downside of using elixir/phoenix and the default code generators in phoenix.

Does anyone have any tips or resources on using files to separate code in elixir?

1 Like

I like. what Sasa does in his talks, eg Clarity | Saša Jurić | ElixirConf EU 2021 - YouTube

3 Likes

I would also recommend reading a multi part series as well that Sasa wrote: Towards Maintainable Elixir: The Core and the Interface | by Saša Jurić | Very Big Things | Medium

That’s one part of the 4 I think, of which every single one has incredible value to be pulled from. Like anything, don’t be too dogmatic about it, it’s very likely you won’t nail it the first couple of times, but as long as you have these concepts in the back of your head, certain patterns tend to emerge.

4 Likes

One trick is to generate a new Phoenix app in some scratch directory, use Phoenix schema etc. generators there, read the generated code, and then implement something similar by hand in your real app, putting everything where you want it.

2 Likes

I’ve observed this as well and I’ve diverged more and more from Phoenix scaffold over time. I think of it kind of like a pattern for a suit. It might work well unaltered for a certain range of people/venues, but as the tailor it’s my job to know who is going to wear it where, and with what shoes, and cut and shape accordingly.

To be a bit more specific, following Saša Jurić I first started managing changesets right in the context, ditching the schema changeset functions. But this does make context bloat even worse so I have started moving create/update functions back to schemas, reserving contexts for true “glue code” (e.g. ‘new registration’ endpoint that creates several rows across tables, and sends an email, etc), something I doubt he would endorse. But on this very forum Saša has given advice contradicting guidance in those articles, so the main thing I follow him on is not being too attached to the purity of abstract rules. More than anything, I hate premature optimization with a passion so I try to always be guided by the domain rather than framework boilerplate, even a framework as well thought out and designed as phoenix.

One caveat: consistency does have a lot of intrinsic value that has to be balanced against this kind of customization/experimentation in a domain, especially when larger teams are coordinating on a project. Sometimes its worth erring on the side of “prematurity” when abstracting domain logic if it keeps everyone on the same page. But personally this is why I avoid larger teams :slight_smile: