Кто работает с микросервисами - есть вопросы
Решил вот тоже попробовать, но вопросов больше чем ответов. В принципе интересует ASP.NET Core 3.1 C#, но общие соображения тоже не помешают.
Фронтенд пока не трогаем пусть останется монолитом, хотя хотелось бы всё закинуть в один сервис. Для блазора решение есть во всяком случае.
Первое - это данные.
Сделал я базу, создал объекты, сделал рестфул апи - микросервис с постманом работает.
Теперь надо его вызвать. Сделал вызовы допустим, но ведь данные должны быть теже самые. То бишь или копия или ссылка.
А как же независимость? Если сервис изменил данные то тоже менять надо на фронтенде.
А базы как разные делать? Пользователь то мне нужен везде один и тот же, и подобных общих объектов море.
Пока остановлюсь...
Если нет, лучше оставить монолит
проблема не в этом. Что когда использовать не сильно интересует.
Задача разобраться с микросервисами и сделать демо приложение.
Микросервисы это всё же о бекенде
ну может название другое, но в идеале хотелось бы иметь "лего блоки" и для блазора + НЕТ 5 такое уже есть.
https://devblogs.microsoft.com/premier-developer/microfron...
Можно мешать Разор с Ангуляром и прочим. По ссылке только идея.
Задача разобраться с микросервисами и сделать демо приложение.
Так это уже давно сделано: Первая попавшаяся ссылка на Гитхабе.
Первая попавшаяся ссылка на Гитхабе.
Для начала нужно сделать самому чтобы понять. Не нашел пока ни одного подходящего проекта 
Что в ссылке не подходит:
10 microservices showcasing Kubernetes, Istio, gRPC and OpenCensus.
и
Нужно ASP.NET Core попроще и без зайцев желательно. Это все следующий этап.
Тут бы получить данные с Рестапи от доскер контейнера 
Данные и вычисления нужно разделять, в этом суть.
Меня немного другое интересует. Данные на сервисе и фронтенде должны то быть одинаковыми. А как же "независимые сервисы"?
AKS в Azure я поднял за 10 минут.
Вообще то хотел дома в докере поиграться, а то за базу с приложением 5-ку драли ежемесячно. Сейчас поотключал всё, хотел глянуть выйдет ли на 0.
А Fabric Azure - это другое? Тоже вроде для микросервисов.
Данные на сервисе и фронтенде должны то быть одинаковыми. А как же "независимые сервисы"?
Какие данные? Что такое данные в этом контексте? Фронт делает запрос по определенному адресу. Определенному. Состоящему из хоста, порта и ендпойнта(ресурса). Нттп запрос . Получает нттп ответ. Что значит "независимый"? Бэкенд отвечает на любой запрос. Фронта, постмана, другого бэкэнда. Бэкенд занимается подготовкой данных к показу или изменению. Фронт запрашивает , бэк вытаскивает данные из одного или многих источников, подготавливает к отправке и предоставляет по запросу.
Пользователь то мне нужен везде один и тот же, и подобных общих объектов море.
Каждый сервис занимается чем то своим. Например сервис пользователей. То есть есть база данных пользователей и доступ к ней только через сервис пользователей. Если нужно что то другому сервису, он не имеет права лезть в чужую базу, а запрашивает данные через соответствующий сервис. Сервисы отдают данные по запросам не только фронту, но и другим сервисам.
Какие данные? Что такое данные в этом контексте?
У меня в есть в базе пользователь, сервис отдает мне например: имя, майл, роль. Для этого у меня есть POCO объект, создаваемый автоматом.
На фронтенде мне нужно получить тоже самое: имя, майл, роль. То бишь нужен идентичный POCO объект.
Теперь я в сервисе добавил телефон, значит нужна синхронизация с бекэндом и другими сервисами. Где же эта декларируемая независимость?
а запрашивает данные через соответствующий сервис
А как же дизайн базы? Удаляю я пользователя - значит автоматом со всех связанных таблиц должно удалится. Опять сервисам всё поручать и сообщения об удалении отслеживать? А если сервис слег и не получил сообщения?
Удаляю я пользователя - значит автоматом со всех связанных таблиц должно удалится.
Для этого есть нормализация данных, это вопрос дизайна БД, это не совсем про микросервисы.
Каждый пользователь и его атрибуты должен писаться один раз (в идеале, конечно).
А если сервис слег и не получил сообщения?
Для этого СУБД должна уметь транзакции
То есть вы атомарный объект описываете атрибутами из разных БД?
Почему атомарный?
Вот есть у меня пользователи на германке.
Теперь хочу сервис теннисные клубы сделать, что бы каждый пользователь мог туда записаться.
Для одной базы мы бы добавили таблицу клубов и затем еще одну клуб-пользователь. Как теперь правильно сделать две базы для сервиса?
