Hi guys, what are your best practices about folder scaffolding for service project?
A common practice I see in many places is to follow the MVC pattern, the same scaffolding that RoR auto generates. But I find it a little bit inconvenient and my solutions don't convince me at 100% all the time. So I made a demo project with the following scaffolding.
+-- config -- Server config files (.yml, .json, .env)
+-- scripts -- all build & deployments scripts
+-- logs -- daily rotatory log files
+-- src
| +-- api -- all the service endpoints
| | +-- endpoint1
| | | +-- controller.ts
| | | +-- model.ts
| | | +-- routes.ts
| | | +-- specs.ts
| +-- business -- the business layer (authentication, server audit)
| +-- components -- (such as loggers, external services consumption)
| +-- config -- configuration middlewares
| +-- data -- data layer
| | +-- repositories // all repositories needed for api/models
| | | +-- endpoint1Repository.ts
| | +-- providers // all data source providers the service could support
| | +-- adapters
With this approach I have all the logic related to an endpoint in the same folder. But I feel that the repositories are a little bit "far".
What do you guys think? Suggestion?
You can see a demo project here (I did it as a proof of concept and to learn a little bit about Firebase and CircleCI)
Top comments (2)
Since you are taking a service oriented approach using a mono repo seems counter intuitive, but might be the right approach at this stage, remember that eventually toy can break things apart and use git submodules to reference external entities.
Yes, in the repo I opted to add a client as sub folder but it should be a submodule or subtree. I wanted to point out only if the service scaffolding will be a good base while the service gets more api endpoints.
Thank you for your answer!