5 ms·
If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this: app ├──
by whilenot-dev 1y ago
If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this:
app
├── controllers
│ ├── task.py
│ └── user.py
├── models
│ ├── task.py
│ └── user.py
├── repositories
│ ├── task.py
│ └── user.py
└── schemas
├── extras
│ ├── current_user.py
│ ├── health.py
│ └── token.py
├── requests
│ ├── tasks.py
│ └── users.py
└── responses
├── tasks.py
└── users.py
A structure around mini apps always turns out to be more beneficial for keeping boundaries intact in the long run:
apps
├── tasks
│ ├── controller.py
│ ├── models.py
│ ├── repository.py
│ ├── schemas.py
│ └── service.py
└── users
├── controller.py
├── models.py
├── repository.py
├── schemas.py
└── service.py
[0]: https://github.com/iam-abbas/FastAPI-Production-Boilerplate https://github.com/iam-abbas/FastAPI-Production-Boilerplate
- hynek 1y agoThe fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.
- shakna 1y agoBogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers. > Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum. That's exactly where you shouldn't be using it! Relying on it as dogma will result in chaos.