Блог

Внутренности моего приложения состоят из набора микросервисов, каждый из которых в основном использует архитектуру DDD.

В стандартном решении MVC клиент будет получать доступ к моим контроллерам, а контроллеры будут взаимодействовать с моими микросервисами.

При настройке сервера Blazor подход будет аналогичным.

Однако с настройкой Blazor WebAssembly (Hosted) у меня есть возможность ссылаться на свои микросервисы непосредственно из клиента Blazor WebAssembly.

Разумно ли это?

Или мне было бы лучше создать фасад на сервере Blazor (который, в свою очередь, обращается к микросервисам) и взаимодействовать с этим фасадом только из клиента Blazor WebAssembly?

Мой сервер Blazor имеет свои собственные потребности для ссылки на микросервисы, и я как раз собирался зарегистрировать микросервисы на клиенте, прежде чем задаться вопросом, разумно ли это.

Это сильно зависит от вашей архитектуры и ее ограничений, и правильный ответ продуман.

BFF

Вы могли бы использовать шаблон BFF (Backend для интерфейса), ваш facede. В этом случае другой микросервис будет действовать как шлюз между вашим приложением Blazor и вашим ландшафтом микросервисов.

Таким образом, интерфейсу не нужно знать, какую информацию в какой службе искать. Обычно это упрощает разработку интерфейса. Кроме того, BFF может решать сквозные проблемы, такие как аутентификация.

Однако вы вводите новый микросервис, который не помогает решить вашу бизнес-проблему. Вы добавляете еще один уровень случайной сложности.

Кроме того, с помощью BFF вы как бы создаете определенную зависимость между вашими службами. Если вы изменяете или добавляете возможности своего микросервиса, вам также необходимо обновить BFF.

Вызывая их напрямую

Если ваши микросервисы имеют своего рода HTTP (REST) API (кстати, не каждому микросервису это нужно), который может быть открыт для общественности (ваш клиент Blazor), вызов их непосредственно из клиента является вариантом.

Каждая служба должна самостоятельно решать сквозные задачи, такие как аутентификация. Клиентам необходимо отслеживать несколько потенциальных подключений к сервису. У них будут разные URL-адреса, но, возможно, также понадобятся разные заголовки и т. Д.

Заключение

Это зависит. Вы лучше всех знаете свою архитектуру, и есть много статей, в которых обсуждаются плюсы и минусы BFF. Я могу порекомендовать начать с этой статьи https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern.

• Мы говорим о 3 или 30 микросервисах?
• Как часто клиент вызывает микросервисы?
• Как часто клиенту необходимо запрашивать несколько служб для создания представления?
• Вы раньше использовали API-шлюз?
• Требуется ли аутентификация или проблема?
• Как регулярно изменяется API микросервисов?

Я надеюсь, что мой ответ поможет вам найти свой ответ. 🙂