マイクロサービスアーキテクチャのフロントエンドとしてSpring MVCを使用することは良い考えですか？
私のマイクロサービスプロトタイプには、現在、フロントエンドとしてSpringブートMVCアプリケーションがあります。アプリケーションは、ビューを完全にバックエンドでレンダリングします。 APIゲートウェイの背後にあるOrderServiceやShippingServiceなどの他のマイクロサービスへの残りの呼び出しを行います。 API Gatewayの背後にあるマイクロサービスのスケーリングは問題ありません。しかし、セッションでフロントエンドMVCをスケーリングすることは、それほど素晴らしいことではないと思います。私はOauth2を実装でき、前面もステートレスに設定できます！？
Angularのような完全なJavaScriptが前に付いたマイクロサービスアーキテクチャの例をよく目にします。ブラウザのJavaScriptクライアントでそれを使用するのは正常ですか？いつサーバー側のレンダリングを使用する必要があり、クライアント側がJavaScriptでレンダリングするのはいつですか？
サーバーサイドレンダリングを使用する理由：すべてのマイクロサービスを自己完結型システムにしたい。 ShippingService（Resource）やOrderService（Resource）などのすべてのサービスには、独自のSpring MVCサーバー側のフロントエンドがあります（サイドと、そのサービスにのみ関連するバックエンド呼び出し用のJavaScriptを提供します）。たとえば、OrderSerivceがダウンしても、配送サービスは完全に使用できます。サービスが利用できないため、OderServiceへのリンクだけは含まれていません。
それ以外の場合、ユーザーにJavaScriptクライアントを提供するWebポータル（Spring MVCアプリケーション）を使用すると同じ動作になりますが、Webポータルがダウンした場合はどうなりますか？
すべての異なるマイクロサービスに関連するすべてのJavaScriptコードはどうですか？常に強い依存関係があるのでしょうか？
また、HTMLをOrderServiceに追加してリンクを提供するだけで、SpringブートMVCアプリを各マイクロサービスに追加するよりも良いかどうかも知りたいです。ユーザーがクリックすると、ブラウザはREST API？の代わりに、OrderSericeによってレンダリングされたHTMLページを表示します。
アーキテクチャーの観点からは、ビューに使用するテクノロジーについては心配しません。私はフロントエンドに角度のようなフレームワークを使用することを好みますが、Spring MVCとクライアント側ソリューションの両方で目的を達成できます。
ただし、適切にスケーリングするには、ステートレスなものを作成する必要があります。さらに、クライアントからのすべてのリクエストは、APIゲートウェイ（認証などの処理に最適な場所）を通過する必要があります。
また、各マイクロサービスにSpringブートMVCアプリを追加するのではなく、それがより良いかどうかも知りたいです[...]
それについては、クライアントが別のマイクロサービスと通信しないことを保証できる場合にのみ、各マイクロサービスに対して1つのビューを作成できると思います。別のケースでは、おそらく単一のビューを作成する必要があります。
これがお役に立てば幸いです。