Phoenix 1.7 directory structure for wrappers

phi

Hi all,

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.

Thanks for any help!

8 comments

/phoenix #project-structure #wrapper

0 592 8

2024-03-27 17:21:44 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

dimitarvp

If you want to future-proof it a little then something like lib/third-party/<service>.ex is an okay way to go about it.

Post #1

krasenyp

I second that. I keep seeing people being afraid of creating directories in lib/ and sometimes even reach for umbrella project.

Post #2

dimitarvp

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.

Post #3

whoiswentz

I like to place all my third-party code inside lib/external/<service_name>/<feature>.ex

Post #4

gregvaughn

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.

Post #5

dimitarvp

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.

Post #6

phi

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).

Post #7

phi

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