Как все хорошо и красиво.
Остается только маленький нюанс.
Почему-то яндекс маркет при всем при этом успешно теряет настройки фильтрации после показа всех фильтров и никак не контролирует статус отложенности для текущего товара, хотя после перехода на полный список видно, что все вроде помнит.
Раньше такой фигни не было.
Еще как хватит. У монолита снаружи видно то, что у микросервисов есть в API Gateway.
Все остальные API внутрипроцессные.
С базой все точно также — бывают модули, требующие себе базу и таблицы, но в отличие от микросервисов, это тоже экзотика.
Почему вы предлагаете одну и ту же бизнес-функциональность тестировать по разному?
Потому что микросервис и модуль в составе монолита — это разные вещи.
В случае монолита у нас будут
Вот как модулю авторизации не работать с базой юзеров
Очень просто: модулю авторизации хватит и абстракции над хранилищем.
Если на тесте микросервиса мы проверяем весь флоу от отработки сетевого запроса от клиента до работы с базой, значит и для модуля мы проверяем то же.
Нет, конечно. Для модуля даром не нужно проверять всю эту микросервисную инфраструктурную мишуру. Ибо модуль авторизации ни за точку интеграции, ни за базу данных не отвечает.
Не делаете реальный http-запрос при тестировании модуля, а стучитесь к роутингу как-то напрямую — не делайте его и при тестировании микросервиса
А вот здесь все с точностью до наоборот. Микросервис — это модуль с навернутым на него веб-API и хранилищем данных. Так что если тестировать сервис, то в отличие от тестов модуля, придется проверять и это.
Модулю не нужен EndPoint для браузера.
Модулю не нужна база.
Модулю ничего не нужно, кроме двух списков контрактов:
То, что модуль обязуется реализовать.
Необходимые модулю для обеспечения пункта 1
Есть модули, которые специализированы на доступе к базе или реализации внешних точек доступа. Но для модулей, в отличие от микросервисов, это экзотика.
Например, модуль авторизации 100% будет отвязан как от конкретной точки доступа, так и от конкретного хранилища данных.
Есть один процесс и это монолит.
А вот бинарных фалов с модулями может быть сколько угодно.
Еще в MS DOS были оверлеи.
В Windows появились dll.
В Linux также есть свои подгружаемые в один процесс бинарники.
Единственный бинарник на процесс в наше время экзотика.
Реализация конкретного API микросервиса может делать вызовы к другим микросервисам и для полноценного тестирования извольте поднимать весь оркестр.
А у модуля никакого WebAPI и тем более базы может вообще не быть. Достаточно обычных ООП-интерфейсов. У монолита WebAPI будут трогать только E2E-тесты.
Я не знаю, зачем вам для тестирования одного конкретного модуля надо запускать монолит целиком.
Модульность затем и нужна, чтобы разрабатывать и тестировать модули можно было независимо.
Протестируем как модуль интегрируется с базой в лучшем случае, но не проверим как он работает с базой.
В том-то вся и штука, что микросервис надо тестировать с клиентом и базой, у модуля же клиентом будет тестовый фреймворк, а с базой напрямую ему работать без надобности.
Ничего, что речь шла о тестирование модуля монолита, умеющего то же, что и один микросервис?
Если каждый модуль нуждается в той же базе, что и монолит в целом, проблема не монолитности, а в качестве проектирования.
Для теста модуля монолита БД может быть не нужна совсем. Или нужна, но те же 10 табличек. Сервису же для тестов в любом случае надо базу и сетевого клиента.
Если для тестов модуля монолита нужны все 500 таблиц, то он плохо спроектирован. Такой же по качеству микросервис также захочет 500 таблиц из базы, которую будет делить еще с 50 микросервисами.
В частичный отказ монолит «умеет» и самостоятельно.
Селективный деплой для монолита сложнее, но также возможен при аналогичном подходе к проблемам совместимости.
Инфраструктура для набора микросервисов, решающих те же задачи, что и монолит — сложнее по построению.
Переход на микросервисы сам по себе ничего не упрощает, но превращает часть внутрипроцессных вызовов в медленные, ненадежные, плохо контролируемые на соответствие соглашениям сетевые.
И все это ради единственного преимущества: селективного горизонтального масштабирования.
Нет. Классы типов — это совсем другая концепция.
Остается только маленький нюанс.
Почему-то яндекс маркет при всем при этом успешно теряет настройки фильтрации после показа всех фильтров и никак не контролирует статус отложенности для текущего товара, хотя после перехода на полный список видно, что все вроде помнит.
Раньше такой фигни не было.
Еще как хватит. У монолита снаружи видно то, что у микросервисов есть в API Gateway.
Все остальные API внутрипроцессные.
С базой все точно также — бывают модули, требующие себе базу и таблицы, но в отличие от микросервисов, это тоже экзотика.
Потому что микросервис и модуль в составе монолита — это разные вещи.
В случае монолита у нас будут
Для микросервиса c той же функциональностью:
Очень просто: модулю авторизации хватит и абстракции над хранилищем.
Нет, конечно. Для модуля даром не нужно проверять всю эту микросервисную инфраструктурную мишуру. Ибо модуль авторизации ни за точку интеграции, ни за базу данных не отвечает.
А вот здесь все с точностью до наоборот. Микросервис — это модуль с навернутым на него веб-API и хранилищем данных. Так что если тестировать сервис, то в отличие от тестов модуля, придется проверять и это.
Модулю не нужен EndPoint для браузера.
Модулю не нужна база.
Модулю ничего не нужно, кроме двух списков контрактов:
Есть модули, которые специализированы на доступе к базе или реализации внешних точек доступа. Но для модулей, в отличие от микросервисов, это экзотика.
Например, модуль авторизации 100% будет отвязан как от конкретной точки доступа, так и от конкретного хранилища данных.
Есть один процесс и это монолит.
А вот бинарных фалов с модулями может быть сколько угодно.
Еще в MS DOS были оверлеи.
В Windows появились dll.
В Linux также есть свои подгружаемые в один процесс бинарники.
Единственный бинарник на процесс в наше время экзотика.
Реализация конкретного API микросервиса может делать вызовы к другим микросервисам и для полноценного тестирования извольте поднимать весь оркестр.
А у модуля никакого WebAPI и тем более базы может вообще не быть. Достаточно обычных ООП-интерфейсов. У монолита WebAPI будут трогать только E2E-тесты.
Я не знаю, зачем вам для тестирования одного конкретного модуля надо запускать монолит целиком.
Модульность затем и нужна, чтобы разрабатывать и тестировать модули можно было независимо.
В том-то вся и штука, что микросервис надо тестировать с клиентом и базой, у модуля же клиентом будет тестовый фреймворк, а с базой напрямую ему работать без надобности.
Двумя сообщениями выше:
Не надо сравнивать тестирование монолита целиком и одного микросервиса.
Один микросервис есть смысл сравнивать с одним из модулей монолита.
Если каждый модуль нуждается в той же базе, что и монолит в целом, проблема не монолитности, а в качестве проектирования.
Для теста модуля монолита БД может быть не нужна совсем. Или нужна, но те же 10 табличек. Сервису же для тестов в любом случае надо базу и сетевого клиента.
Если для тестов модуля монолита нужны все 500 таблиц, то он плохо спроектирован. Такой же по качеству микросервис также захочет 500 таблиц из базы, которую будет делить еще с 50 микросервисами.
Селективный деплой для монолита сложнее, но также возможен при аналогичном подходе к проблемам совместимости.
Переход на микросервисы сам по себе ничего не упрощает, но превращает часть внутрипроцессных вызовов в медленные, ненадежные, плохо контролируемые на соответствие соглашениям сетевые.
И все это ради единственного преимущества: селективного горизонтального масштабирования.