“How to make and maintain a project in framework X with the minimum amount of files and boilerplate” 
3 Likes
Well with the minimum amount files resonates to me as that huge files of code that do not separate concerns and actions.
I am not really a fan of one file to handle all the actions one a resource, but this is often the case, but what pisses the heck of me is when the files goes to the thousands of lines and deals with many resources… it’s just a nightmare and a sink hole of our time 
But probably the minimum amount of files you are referring to are not related with the code for the project itself?
2 Likes
^^ Sounds like a good topic for a thread
Rails championed a simple MVC structure which many frameworks also adopted. However I really liked Volt’s idea of building your app as a series of components. Something that bugs me is when I am working on something then have to jump to various folders. I know editors like Vim can make it easier but sometimes I just want to use the side panel file browser to get where I want to.
2 Likes
What I mostly aim at is the fact that programmer confusion increases exponentially as file count in a newly generated project grows. Generate any project, get 50+ files, and most people are like “WTF, why so much? What do file A and B do?”.
When generating most Phoenix projects that I did for play or consulting people and companies, I noticed that most boilerplate never gets touched even after the project is developed by 3+ people for a solid year or more. So then you could unite almost everything Phoenix-related in a single file (minus the router; that really should stand on its own).
Examples:
- Most people never use the
*_view.exfiles. - Most people never have several layouts.
- Most people never customize their
Repofile much (just a few lines extra). And almost no people have secondary / tertiary / etc.Repoat all as well. - Most project’s
*_web.exfile is never customized.
You get the idea. My point is that these present several possibilities to merge the contents of such files into one – with a big CAPS DISCLAIMER on top – just to religiously pursue the “minimum amount of files” mantra.
But I long ago recognized this is a personal taste and I found that many other people don’t mind more and smaller files when they generate projects – after all, the moment you need those files you have them right there where the generator left them. Imagine if you only had myapp_view.ex file! Many would be confused when they need a custom view module because the files aren’t there and they’ll have to create them manyally. A lot of programmers are very afraid to do that (and I was one of them). They think this goes “against the framework” and I can’t blame them; when you have tools generating your project and enforcing a certain structure then it’s hard to assume that it’s safe to just do whatever you want afterwards.
The way my idea would actually work is to have very intelligent code generators that are able to transform between both things with a single command. But that’d require parsing abilities at the level of the Elixir compiler itself. Plus I have a ton on my plate – still settling on the new job and I am not at the “happy place” yet (not so productive as I like, having to learn stuff that I hate like Kubernetes etc.) – and I am not sure I’d ever get to such a project. But I’d love to.
1 Like
If the project is well organised I don’t think this would be a problem, less so than everything being in one mammoth file imo 
The “one file” was obviously the other extreme to illustrate a point. I wouldn’t ever want to have any such plumbing and platform boilerplate file being more than 100 lines (sometimes 200, depends); the moment it grows beyond what I find comfortable to skim then I’d immediately split it in two.
I’d even give the directories and files more boring and non-flattering names like lib/phoenix/boilerplate_web.ex (Phoenix’s Endpoint is a good candidate here) or lib/ecto/plumbing.ex (where I’d put Repo configuration). Just to make people painfully aware that this is code that absolutely needs to be in your source-control repository but you’re not supposed to touch it unless you have special needs.
1 Like
That’s true when you use traditional folder structures inherited from MVCs kind off approaches, but not when you group code by the action performed on a resource:
src/Resources/
├── Carts
│ ├── New
│ ├── Modify
│ ├── View
│ └── Remove
├── Categories
│ ├── New
│ ├── Modify
│ ├── View
│ └── Remove
├── Checkout
│ ├── New
│ ├── Modify
│ ├── View
│ └── Remove
├── Clients
│ ├── New
│ ├── Modify
│ ├── View
│ └── Remove
├── Products
│ ├── New
│ ├── Modify
│ ├── View
│ └── Remove
└── ...
This is my approach to structure code in any personal project I work in, and also use in one of the last projects I have worked on in my previous role.
In my opinion, and as I was able to observe, anyone looking into the Resources folder can immediately see what Resources and what actions are available for each one
without the need to consult any documentation.
So this is the folder skeleton acting as documentation in our projects.
Projects structured in this way are not hard to navigate or remember where things need to be placed.
2 Likes
This is something like aspect-driven development – or domain-driven? I can never remember all the buzzwords. And yep, I find it more logical as well. Arranging things by framework artifacts – models, views, controllers, layouts, templates, GraphQL resolvers etc. – always made me struggle.
But it’s a fact that modern IDEs – including very helpful bundles of plugins for VIM and Emacs – make browsing code easy. I still like to know which is where though.
1 Like
I call it Resource Design Pattern, but a colleague at work called it more correctly of Resource Action Pattern, and I may end up to rename the repo
I created it before I was aware of Domain Driven Design, and never heard of Aspect driven development.
2 Likes
Well it will never be the same as having code grouped by the action they perform on a Resource. It’s just so intuitive, that you don’t need any help
2 Likes
Have split these posts into a new thread as I think it will be an interesting discussion (If you think we need to change the title let me know).
1 Like
This was one of the main problems with the first popular MVC web framework for Java: Struts1.
It’s hard to understate how popular Struts1 was in the Java community circa 2003.
Therefore, it grew rapidly and organically, and unfortunately this resulted in all roads leading to struts-config.xml.
The file could balloon to thousands of lines, especially if you wanted readable XML, and merge conflicts were a constant source of worry on larger projects.
3 Likes