До изобретения микросервисов бизнес выделял много времени на проектирование сложных систем с использованием доменной модели. Однако, новые условия рынка потребовали урезать бюджет IT отдела, чистая архитектура оставалась в голове программиста, а код писался только исходя из сию минутной выгоды. Однако, подрастающее поколение специалистов изучают программирование в режиме закрыть максимальное количество пунктов резюме, при этом, вопрос повторного использования другим специалистом кода не рассматривался, так как за будущие проблемы не платят деньги. То что такое поведение коллег по меньшей мере не культурно не является сутью вопроса, проблема в том, что плохой код пораждает незаменимых специалистов и, при уходе такого специалиста, так как передать работу полностью технически невозможно, срыву проекта в средней временной перспективе
Проблему можно избежать техническими методами, грамотно декомпозировав код между микросервисами. Ранее, доменная модель Model View Controller позволяла удерживать читаемость проекта так, чтобы специалиста можно было быстро подменить, однако, так как ООП языки (Java, C#) используют пространства имен для разделения модулей, требовалось писать код в монолите.
С появлением монорепозиториев проблемы можно избежать, грамотно организовав структура проекта на старте. Данный проект представляет собой микросервисную архитектуру, где host (папка apps) приложения взаимодействуют с микросервисами (папка services) через шину событий GRPC, повторно используя общий код луковичной композиции сервисов со слоем логирования и базы данных из общего кода (папка modules)
Крупные приложения пишутся в Domain Driven Design. Частным случаем этой архитектуры является Model View Controller в монолите. Этому учат в университетах, найти кадр просто. Однако, чтобы проект держал нагрузку, нужен микросервис. Найти хороший кадр, который сможет поддерживать ООП код в микросервисе, а не процедурный, сложно.
Чтобы разрешить проблему процедурного кода в микросервисе, был разработан starter kit масштабируемого NodeJS микросервиса в монорепозитории
- Работа с gRPC через TypeScript
На момент 2016 года не было разделения commonjs и esm модулей и Typescript, поэтому файлы proto предлагали конвертировать в js сомнительного содержания. В этом starter kit архитектура подразумевает доступ через sdk object с поддержкой IntelliSense, проблема генерации d.ts из proto решена скриптом на js без нативного бинарника
- Запуск backend без docker через
npm start
Иногда, нужно получить доступ к js файлам без изоляции, чтобы просмотреть работу отладчиком или добавить в уже транспилированный бандл console.log. Для запуска микросервисов используется PM2
- Единый источник ответственности для работы с базой данных
Для работы с базой данных лучше использовать луковичную архитектуру Model View Presenter, где слой представления организует маппинг и логгирование взаимодействия c данными, слой сервисов базы данных осуществляет абстракцию от СУБД. Проблема масштабируемости этого паттерна решена вынесением кода в общий модуль, упрощенно, каждый микросервис может разместить в себе копию монолита.
- Выполнение методов микросервисов без Postman
Хост приложения, осуществляющие взаимодействие с сервисами по gRPC лежат в папке apps. Было создано два приложения: apps/host-main и apps/host-test, первое с веб сервером, во втором можно написать произвольный код и запустить его командой npm run test. Так же, в apps/host-test можно писать юнит тесты, если нужно вести разработку тестированием