Node Modular Architecture : <p>I am building a nodejs application that is fairly large now. In an attempt to avoid a monolithic node application I have gone down the architectural route of a more modular system breaking out several components into separate npm modules. These are published using npm and installed in the dependent modules. I have about 6 different modules (which I would want to break out in to more) and now it has become difficult to manage the packages.</p>

<p><strong>The problems</strong> are:</p>

<ol>
<li>There is nested dependency so if I change module A and module B depends on module A and module C depends on module B, then when I update module A I need to publish a new version of it, which then means I need to update it in module B, which means I also need to publish of that and then finally I need to install that new version in module A ... you can see where that might be a pain. What's more the updating of the versions in all the package.json is manual and so error prone, and waiting for each publish is time consuming.</li>
<li>Modules can share npm dependencies and so sometimes conflicts occur when packages get updated. The more modules the higher the chance of conflict.</li>
</ol>

<p><strong>The benefits</strong> are that we have a very modular system where libraries can be reused easily and there is a clear hierarchy of modules enforced as there can't be any circular dependencies.</p>

<p><strong>Possible solutions</strong> are:</p>

<ol>
<li><p><strong>Monolith</strong> - To manage the dependencies as a single app in a single repository with each module just becoming a services. This means that only one update is necessary and all the module apis will be in sync. However, referencing the libraries in the code might be a bit of a pain (as I believe they will have to be referenced relative to the local file), I am not sure how a structural hierarchy between the modules can be enforced and code reuse will be harder with modules outside the repository.</p></li>
<li><p><strong>Microservices</strong> - To make each module a micro service. This maintains all the benefits of the modular system, but I am concerned that it will add a lot of complexity to the build and managing all the services will become a full time job in itself.</p></li>
<li><p><strong>Keep going</strong> - Work out a way to keep the current architecture but remove the trouble of pushing updates etc. Maybe scripts to update versions and shrinkwrap to ensure correct dependencies. I think this would both be difficult and would potentially lead it to being a monolithic system of a different variety.</p></li>
</ol>

<p>Option 1 seems the most manageable to me but I don't want to lose the modular structure if I don't have to.</p>

<p>This is quite a broad question, but any suggestions/advice/comments would be really helpful.</p>

<p>Thanks</p>
