Blazor WebAssembly (размещенная) стратегия MicroService
Суть моего приложения состоит из набора микросервисов, каждый из которых в основном использует архитектуру DDD.
В стандартном решении MVC клиент будет обращаться к моим контроллерам, а контроллеры будут взаимодействовать с моими микросервисами.
В настройке Blazor Server подход будет аналогичным.
Однако с настройкой Blazor WebAssembly (размещенной) у меня есть возможность ссылаться на свои микросервисы непосредственно из клиента Blazor WebAssembly.
Это мудро?
Или мне лучше создать фасад на сервере Blazor (который, в свою очередь, обращается к микросервисам) и взаимодействовать с этим фасадом только из клиента Blazor WebAssembly?
У моего Blazor Server есть свои потребности в ссылке на микросервисы, и я как раз собирался зарегистрировать микросервисы и на клиенте, прежде чем задуматься, разумно ли это.
Ответы 1
Это сильно зависит от вашей архитектуры и ее ограничений, и правильный ответ — правильный.
лучшая подруга
Вы можете использовать шаблон BFF (Backend for Frontend), ваш facede. В этом случае другая микрослужба будет выступать в качестве шлюза между вашим приложением Blazor и вашей средой микрослужб.
Таким образом, внешнему интерфейсу не нужно знать, какая информация находится в каком сервисе для поиска. Обычно это упрощает разработку фронтенда. Кроме того, BFF может решать сквозные задачи, такие как аутентификация.
Однако вы вводите новую микрослужбу, которая не помогает решить вашу бизнес-задачу. Вы добавляете еще один уровень случайной сложности.
Кроме того, с BFF вы как бы создаете некую зависимость между вашими сервисами. Если вы изменяете или добавляете возможности своего микросервиса, вам также необходимо обновить BFF.
Звонок им напрямую
Если ваши микросервисы имеют своего рода HTTP (REST) API (кстати, не каждому микросервису это нужно), который может быть доступен для общественности (ваш клиент Blazor), можно вызвать их напрямую из клиента.
Каждая служба должна самостоятельно решать сквозные задачи, такие как аутентификация. Клиентам необходимо отслеживать несколько потенциальных подключений к службе. У них будут разные URL-адреса, но, возможно, также потребуются разные заголовки и т. д.
Заключение
Это зависит. Вы лучше знаете свою архитектуру, и есть много статей, в которых обсуждаются плюсы и минусы BFF. Могу посоветовать начать с этой статьи https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the -api-шлюз-шаблон.
- Мы говорим о 3 или 30 микросервисах?
- Как часто клиент вызывает микросервисы?
- Как часто клиенту нужно запрашивать несколько сервисов для создания представления?
- Вы использовали шлюз API раньше?
- Нужна ли аутентификация или проблема?
- Насколько регулярно меняется API микросервисов?
Я надеюсь, что мой ответ поможет вам найти свой ответ. :)
Спасибо за комментарии... и полезную ссылку. Я пришел к выводу, что подход API-Gateway (фасад) — это то, что нужно, несмотря на дополнительный уровень, главным образом потому, что я могу централизовать вопросы безопасности и оркестровки микросервисов.