Кто работает с микросервисами - есть вопросы
А в итоге получается и фронтенд монолит и база можно сказать монолит.
------
Получается.
Ровно до тех пор, пока не сможешь разделить на изолированные части.
Какого тогда все просто помешаны на этих микросервисах?
-----
Как для меня - там, даже если пишут спагетти-код, кода будет меньше и взаимодействие с другими частями будет более расписанное.
Например сервис пользователей. То есть есть база данных пользователей и доступ к ней только через сервис пользователей. Если нужно что то другому сервису, он не имеет права лезть в чужую базу, а запрашивает данные через соответствующий сервис. Сервисы отдают данные по запросам не только фронту, но и другим сервисам
то есть скажем для сервиса загруженных пользователями котиков нужна отдельная БД?
а как там сохранять информацию об авторе картинки с котиком?
Где же эта декларируемая независимость?
Нигде и никогда. Проггеры используют какую нибудь систему типа sswagger или просто договариваются. Объект можно прислать в теле запроса или по частям как параметры запроса. Но принимающая сторона должна знать, что принимает. В принципе можно пропарсить ответ и вычленить все отдельные параметры по принципу ключ-значение. Без готового объекта. Но что потом делать с незнакомыми параметрами? Получатель должен знать , что он будет получать и быть готовым к получению. Ну и на этом базируются системы автоматической валидации полученного объекта - параметр xyz например не может быть короче 5 символов, иначе ошибка.
А тут все сложно. Вообще в бэкэнде есть слой управления данными. И именно он решает, как делать трансакции с многими источниками. Например откатить или не производить операцию, если один блок отказал. Или использовать очереди сообщений. Или асинхронно производить операции одну за другой. Но это плата за модульность.
Какого тогда все просто помешаны на этих микросервисах?
Во первых модно. Во вторых даже монолит можно написать модульно. Доступ к данным только через интерфейсы. Это позволяет выкинуть модуль полностью. Заткнуть интерфейсы и прога будет работать дальше. Когда нет сложных перекрестных ссылок и можно переписывать и выбрасывать модули не боясь поломать прогу.
Основная идея имхо - возможность беспроблемно заменить кусок проги не убив остальные части. Ибо только группа микросервисов образует прогу.
Во вторых даже монолит можно написать модульно
Именно это и смущает. В общем, плевать на помешательство. Делам модульно, а если приспичит можно и на микросервисы модули переделать.
Но вот копировать ли общие данные или передавать их по ссылке из одного источника? Скорее второе с версиями.
Вот тогда еще непонятка - сервисы можно размещать где угодно. Как же тогда с защитой, каждому сервису секурити токен еще добавлять?
Монолит можно написать модульно, но это все равно будет монолит. Большое нескалируемое нечто с бутылочными горлышками.
Данные по умолчанию копировать, но только те, что действительно нужны. Все как в жизни.
Если у вас поменялся почтовый адрес, то вы сообщаете об этом банку, врачу и прочим и они у себя меняют данные в базе, а не делают кажный раз
запрос в ратушу перед тем как послать вам по почте счет.
С защитой так же. Получаешь у специального сервиса (ратуша) токен (аусвайс) и таскаешь с собой пока он валидный (10 лет). Стал невалидный - обновляешь :-)
А каждый сервис как-нибудь сам решает что с этим токеном можно, а что нельзя.
Как же тогда с защитой, каждому сервису секурити токен еще добавлять
Есть Аутентификацион-сервер. Он управляет безопасностью. Первый запрос на любой сервис идёт без токена, поэтому перенаправляется на этот сервер, который даёт возможность аутентифицироваться. По результатам процедуры запрос получает токен и перенаправляется обратно. И обрабатывается. Выглядит для юзера это прозрачно - что бы он на бэке не запросил, неважно через клиент или другим хитрым способом, любой сервис выбросит его на регистрацию и потом любой примет с токеном.
Монолит можно написать модульно, но это все равно будет монолит
Ну есть у меня допустим 3 интерфейса, имплементация для которых лежит в 3 разных Длл-ках - тип модульный монолит
Теперь эти 3 интерфейса "имплементируются" через сервисы - тип микросервисы
Ну и где будет разница?
Данные по умолчанию копировать
То бишь, у меня сотня автогенерированных "таблиц" и все мне их ручками копировать/перебивать?
А потом все синхронизировать? Кто интересно будет мне план синхронизации писать, чтобы всё точно было?
пока он валидный (10 лет).
Токен валидный 10 лет - это где 
Надо стащить и попользовать 
Большое нескалируемое нечто с бутылочными горлышками.
На самом деле нет. Монолит это много сервисов вместе. Масштабировать можно так же, как и каждый сервис в отдельности - если ресурсы не имеют состояния. Просто это будет один проект. Возможно гигантский. Я знаю проект, где нужно загрузить пару тгигобайт всякой хрени, что бы работать над одним модулем.
С токенами как правило тоже все единообразно - общая политика безопасности. Даже если много отдельных сервисов.
В общем, каждому сервису еще и "логин часть".
Я не сильно понял, что это значит, но это стандартная защита вебресурса. Неважно, защит он в монолите или в отдельном сервисе. Каждый ендпойнт защищён. Каждый, кроме специально открытых. Каждый отвечает на запрос с правильным токеном или посылает за токеном. Если это защита на базе токенов.
То бишь, у меня сотня автогенерированных "таблиц" и все мне их ручками копировать/перебивать?
Я не понял проблему. У каждого сервиса свои таблицы. Каждый сервис хранит и управляет только своими данными. Сервис "пользователь-штаммдаты" имеет таблицу "адреса" и ее и данных по адресам нет больше нигде.
Каждый ендпойнт защищён.
По типу ентого?
[Authorize]
public class HomeController : Controller
Я имел в виду немного другое.
Если сервис обращается к сервису то там тоже ведь нужна защита. А токен я обычно получаю после отсылки "имя+пароль", получается каждый сервис должен иметь свою пару, которую тоже в принципе можно стыбрить.
У каждого сервиса свои таблицы
Ну так эти данные как-то должны попасть фронтэнду, пусть они и замапенны с дополнительными атрибутами для валидирования, но все равно это "копия" оригинальных таблиц сервиса. И эту копию должны синхронизировать разработчики сервиса, а не те кто пишет UI.