Another comment regarding "1.1 Structure your solutions by business components"

Nobody has claimed this yet.

Hi everyone! First, thank you so much for this resource that helps me not to forget important points while working on my platform that heavily relies on Node.js services.

I recognized that some of your best practices and especially your boilerplate code generator Practica "steer" people in the direction of microservices. I also thought of microservices while working on the initial system design of my platform, that will run on Google Cloud and Firebase. I decided against it because from my point of view it's too complex and also too expensive to start with. First, it is not feasible for me to run multiple DBs simultaneously. I cannot (or should not) scale them to zero and DBs are expensive to run 24/7. Second, while the latency caused by all the communication between the services via network isn't an issue for me (because I won't have thousands of reqs/second from the very beginning), the costs that come with exponential traffic might be an issue. I want to keep operational costs down. Furthermore it might be that I cannot scale services down to zero. It is more expensive to keep multiple services alive than just one. Third, the operational effort for deploying, running, monitoring and maintaining 10 instead of 1 or 2 services is immense for one or two people that need to handle thousands of other tasks, mostly not related to IT stuff but organization, acquisition, communication, support, etc. Sure, there are amazing tools and possibilities like CI/CD pipelines listening to small code changes and automatically deploying and starting new images; or infrastructure as code that can start the whole infrastructure at the press of a button. But learning these things takes hours, days, weeks, even years. As a guy who is starting up a project in his spare time, I cannot afford this. I need to keep things simple - at least at the beginning and until I can afford a team supporting me. (I don't want to go the common "startup" way that involves shiny marketing and shady contracts to get a few bucks so that I can hire someone who then needs to be coordinated and managed.)

But how can I "prepare" my system design, my structure and architecture so that it can grow naturally? What can I do **now** at the beginning so that I don't have to start over again if I want to enhance my system or if I want to replace a component with another? There are multiple reasons to go for microservices, or at least for a highly modular and decoupled design: As my startup grows, multiple people can work on different components without needing to understand the whole system or disturbing each other. When I identify some bottlenecks, a modular and loosely coupled system makes it easier to switch to another technology or programming language to optimize this specific component. Furthermore, microservices make it easy to scale components independently. So you can save lots of money because you don't have to multiply (= scale horizontally) the whole system.

But as I said: How can I manage the balancing act of keeping the system simple (easy to develop and to operate) and cheap on the one hand, but modular, expandable, and scalable on the other hand?

I would love to see such considerations and discussions in this repo. And I would like to get it started by sharing 2 (ugly) drafts I quickly prepared. The one picture shows a more decoupled microservices design with services communicating via network. All services have their own DB and clear interfaces so that other services can connect to them easily. The other picture shows a monolith with a component structure as you mentioned in best practice 1.1 Each component has its own schema and its own DB tables (in the same DB). The components cannot run independently (its a monolith or one docker container) but have clear interfaces so that other components can have "client functions" communicating with these interfaces.

I haven't had the time to write code examples but I will.

I really look forward to a valuable discussion. Thank you in advance!

Picture 1: Microservices decoupled

Picture 2: Easier design but with Microservices in mind

EDIT: I have to figure out if its possible to define a single DB with different Prisma schemas containing separate tables. Don't know if this is possible by design.

Start with section 1.1, the two architecture diagrams, and the author's discussion of Node.js services, Google Cloud, Firebase, and Prisma. The issue does not name files or tests; done would require an agreed documentation scope and concrete examples or guidance addressing simple, modular architecture.

Written by the indexing model from the issue text.