Макс Никитин

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

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

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

Посмотрите на Sails, у них как раз такая штуковина реализована.

я думаю вам рано браться за angular, раз вы еще не знаете что такое замыкания, объекты, функции, контекст функции...

$scope.user = {
    auth: false,
    id: 33,
    name: '',
    lname: ''
    abs = 'some text'
}

но на будущее: старайтесь инкапсулировать логику в сервисы. То есть если у вас в контроллеры инджектятся сервисы типа $http, то что-то явно пошло не так на этапе проектирования. Это все должно использоваться внутри ваших сервисов, и контроллеры о том откуда берутся данные знать ничего не должны.

В идеале это должно быть как-то так:

angular.module('app', [])

.controller('MainCtrl', function ($scope, userRepository) {
    userRepository.getUser().then(function (user) {
          $scope.user = user;
    });
})

.factory('userRepository', function ($http, $q) {
    return {
        // метод возвращающий данные пользователя
        getUser: function() {
              // забираем данные с сервера
              return $http(/** опции запроса */).then(function (response) {
                  return response.data; // возвращаем данные пользователя
              });
        }
    }
});

потому что require "исполняет модуль" единожды,
при повторном подключении он возвращает уже загруженный ранее модуль
mongose видимо имеет внутреннюю регистрацию моделей.