@ChiperSoft could you explain some of it in an email to me?
I suspect you may already have a general idea about it, since you've been arguing in favor of micro-services for some time. The basic idea is that you break your site down into lots of small applications.
Say you have a portal that is composed of multiple sections: front page, news, video, sports, discussion board, weather, video, etc. Each of those different sections would have their own backend content services driving them, independent APIs integrating with their own databases. You'd also have some form of centralized login & identity management service, some form of access control, and maybe a service for managing white-labeling if your portal is licensed by other companies.
Each of these sections on the site is a nodejs application by itself, responsible for handling only its own requests. This may be built using node's built in http server routines and a lot of in-house code, but most people are using some derivative of Sencha Connect such as Express or Restify. Connect handles a lot of the heavy lifting like routing, session management, cookies and the like. You'd probably use something like Request.js to handle the communication with the backend services, and probably Memcache, Redis or Cassandra as a caching/session management solution. Individual controllers handle incoming requests, and pull/push data from/to the backend services or the cache. For AJAX API requests that could be as simple as piping the service output directly to the visitor, but for page content it could mean calling multiple services to gather data together for a view, and that view rendering one or more mustache/handlebars templates. Component driven development has a large impact here, as you can break page elements into distinct modules with their own templates, and reuse the modules on the front-end for ajax live updating.
Each individual app runs on its own port and only worries about handling its own requests. They each have their own isolated memory stack and event loop, and can be all running on one box or running separately on individual boxes. If you build it properly you can distribute different applications with different demand levels in different configurations. Eg, you'd distribute the front page across lots of boxes, but low demand elements like a careers page and contact system could run together on a single box.
All of these individual applications would then be aggregated by a proxy layer, such as nginx, varnish or amazon load balancer. Requests to /news get forwarded to whatever port news is running on, /weather goes to the port weather is on, etc. This also means that if your site is small enough to run on a single box, each section of the site has its own execution thread. If one section is getting more demand than the others, but not so much that it needs its own box, you can fire up multiple instances of an app and load balance between them.
Each app can have its own repo, and the developers only need to run the app they're actually working in. Static assets can be managed any way you want. Any shared libraries that get used across multiple apps can be either put in a common node include path, or referenced as node modules in the individual app dependencies.
As for organizing the code within the individual applications themselves… that's a topic for another email.
Do you if anyone has done this the concept on the you. So you would have several SPA's. ,then an SOA on the backend. I guess like portlets, but not appreciations, but features. Then you can reuse features in many applications. Have you heard of this design before?