I’m just getting back to learning Phoenix 1.7 after a small hiatus and I’m building a simple one-page site that connects to a Marketing Email API. Maybe I’m overthinking it, but I was wondering where one would go about placing an Elixir wrapper file for the API integration?
I was thinking it would just go in lib/hello/mailchimp.ex for example, or is there a better organization structure? Doesn’t really matter this specific small project, but was thinking for larger projects I could have many such files.
Elixir being both (a) explicit and (b) giving freedom can really be paralyzing. Many people, myself from the past included, were being PTSD’d into submission by very opinionated frameworks.
I’ll be the contrary voice. I would not create a subdirectory until it is needed
I’ve dealt with codebases that over time had all sorts of different opinions on how to organize the source code. I learned to fuzzy find a module by name in my preferred editor. I almost never even notice the directory structure when I’m coding.
It is important to understand that at runtime all modules are in one flat namespace. Runtime relationships between modules are much more important than where the source is on the filesystem. I think of it like code “in action” is runtime and code “at rest” is directories on the filesystem. Yes, some people want to use the filesystem to suggest those runtime relationships, and that’s admirable, but it also can become incorrect. The source of truth is the runtime.
Yeah same and I do agree with your stance, it’s just that as you said it’s basically an aesthetic suggestion for anybody else who doesn’t use fuzzy searching and/or people browsing the project from GitHub’s web UI.
Beyond those use cases the relative path of the module indeed has zero value.
I always appreciate the contrary opinions, and I do agree especially for smaller projects.
The one downside I see from working with other engineers is that for larger projects they might judge you for having many files in a flat structure (and possibly the same with people that look through the codebase looking to hire you, although one would hope code quality would weigh more heavily).
Agreed, especially coming from large monolithic Rails apps, I’ve noticed a lot of engineers prefer things set up very precisely, which now looking back, the PTSD from those experiences is probably why I posted the question to begin with