Тимур Шемсединов

Я бы не противопоставлял монолитные приложения и микросервисы. На самом деле чем лучше приложение разделено на части, тем лучше оно централизовано. Приведу сначала пример житейский, если каждый сотрудник автономно выполняет порученную ему работу хорошо и качественно, то сокращается взаимодействие между сотрудниками, уменьшаются расходы времени на контроль и переделывание работы, при этом монолитность иерархических структур упрочняется чем более автономен каждый сотрудник в организации. Что же противопоставить, что же плохо? Плохо - смешивать уровни абстракции, в ноде распространено смешивать все в кучу, я приводил пример тут: habrahabr.ru/post/247543 цитирую:

Прикладной код часто смешан с системным. Дело в том, что нода, и большинство производных фреймворков, слишком низкоуровневые и каждое приложение обязательно содержит часть системного кода, не относящегося к задачам предметной области. Вот и случается, например, что добавление HTTP заголовка становится методом класса Patient и находится в одном файле с заданием роутинга URLов к сему пациенту и с отправкой событий через веб-сокеты. Это чудовищно.

Монолит - это не плохо. Плохо, когда смешаны слои абстракции, если это не понимать, то микросервисы ничего не дадут. Это приводит к высокой связанности кода, когда каждый фрагмент зависит от множества других. Внутри каждого микросервиса можно сделать полное месиво абстракций. Лучше планировать архитектуру слоями, ниже - слои системные, выше - прикладные. Иногда их нужно 2, иногда 3, иногда больше. В каждом модуле, конечно у вас будут как минимум: внешний интерфейс (содержащий внешние вызовы и спецификации форматов данных для обмена), внутренняя логика и внутренние структуры данных. Задача архитектора сделать так, чтобы интерфейс модуля экранировал внутренние структуры данных и внутреннюю логику от зависимостей. При этом, делить приложение на сотни процессов не обязательно, даже внутри одного процесса вы можете связать компоненты по принципу микросервисов, посадив их на шину событий, это будет называться модель акторов.

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!

Вот Вы пока боитесь ноды, это все из-за неуверенности в новой и незнакомой технологии. Не бойтесь и смело пишите и API на ноде, и маршрутизатор на ноде, и статику нодой отдавайте, и подписку клиентов на серверные события тоже на ноде делайте. Однородность технологий стоит того, чтобы в ней разобраться. Я конечно специалист не по Java, но Абсолютно не ясно, почему вы думали использовать Java Spring MVC для бэкендов. По сути бэкенды - это API, реализованные или как RPC (stateful, взаимодействие с сохранением состояния на обоих концах) или как REST (stateless, взаимодействие без сохранения состояния). При чем тут MVC к API ? Что должен делать API, так это организовывать доступ к БД, обработку данных, выдачу ответов в нужном формате (пусть JSON), ну и в зависимости от того RPC у или REST - API может или хранить состояние в памяти или не хранить его, делая отдельные запросы независимыми, но лишая нас возможности кешировать объекты предметной области в памяти в рамках сессии. По этому поводу полезный ответ я оставил вот тут - http://toster.ru/q/49346#answer_183494

Теперь про матрешки, чтобы от них уйти в написании API, проще всего использовать async. Основная проблема в том, что нужно сделать несколько запросов в БД и потом на основе всех фрагментов данных, полученных асинхронно, исполнить бизнес-логику и сформировать ответ.

var dataRequests = [];
// массив запросов к разным данным (БД, файлы, сетевые вызовы)
var dataResults  = {};
// я предпочитаю не использовать массив results, который дает async
// а вместо этого делать именованные фрагменты данных
// и писать их в свой хеш

// добавляем один запрос к данным
dataRequests.push(function(callback) {
	db.queryRow(
		'SELECT * FROM TableName1 where Field1=?', [someValue1],
		function(err, res) {
			dataResults.firstPiceName = res;
			callback(err, null);
		}
	);
});

// добавляем второй запрос к данным
dataRequests.push(function(callback) {
	db.queryValue(
		'SELECT count(*) FROM TableName2 where Field2=?',
		[someValue2],
		function(err, res) {
			dataResults.secondPiceName = res;
			callback(err, null);
		}
	);
});

// вызываем массив запросов асинхронно
async.series(dataRequests, function(err, results) {
	// тут делаем бизнес-логику над dataResults в котором у нас есть
	// все фрагменты данных .firstPiceName и .secondPiceName
	// и формируем общий результат
});