Your problem is common. It’s about how to organize your code. You’re good enough to solve the problems you need solving but you’re not experimented enough to m

Your problem is common. It’s about how to organize your code. You’re good enough to solve the problems you need solving but you’re not experimented enough to make the code organized. Code that’s well organized is easy to read, reason about, and refactor. I don’t think there are books about this, and there is no right answer to these kinds of problem. My advice is that code organization should come from code growth. Spaghetti code is not that big a deal when it’s small, but you should realize when it becomes a problem a reprganize accordingly. It usually is hard. You need to split your code conceptually, and choose your abstractions and how you group files together What I try to do is split the code into layers on who’s working on what. The node guy will own the basic layer. Then you’ll have the business logic guy who will build the api. Then the frontend guy, etc. These people should be able to work together without stepping on the other guy’s toe. That in my humble experience is a good driving principle. This will make you define clear boundaries. For instance, writing a sql query from within a UI event handler is clearly breaking that principle.