GraphQL Federation によって、マイクロサービスをより細かい単位で構成することができます。
サービスを小さくできるということは、多様なシステムに組み込みやすくなります。
小さいということは、ロジックも、複雑にならずに済みます。
複雑じゃないということは、バグも少なくなるし、開発効率も高くできます。
良いこと尽くめだけど、性能についてはやや気になります。

ここまでは、サーバーサイドの話です。

フロントエンドは、どうなるかというと、通常は、1つのアプリとして実装されます。
SPAとして構築する場合は、React や Vue、Angularの1種類を選択して開発することになります。
サーバーサイドのようにマイクロに分割するのが難しいです。
難しいというか、webpack などで、1つにパッケージングしてリリースするのが一般的で、静的に統合buildするというのが定石となっています。
1つのモジュールを小さくできたときのメリットは、上記のサーバーサイドのそれと同じなので、なんとかしたいものです。

そんな悩みを解決してくれそうなのが、マイクロフロントエンド です。

フロントエンドも、マイクロに分割独立させようというものです。
webpack などがそれを実現するモジュールフェデレーションという機能を提供していて、主要ブラウザもサポートしているので、安心して舵を取ることができます。

面白いのは、React、Vue、Angularが混在して使えるという点です。
例えば、ユーザー管理マイクロサービスと対になる形でユーザー管理フロントエンドをReactで開発していて、リソース管理も対になる形でフロントエンドをVueで開発して、それを1つの画面にガッチャンコできるということ。
まぁ、大規模な開発で複数チームが混在する場合はあるだろうけど、小中規模では、あまりそこまで極端な開発をすることはないとは思います。

モジュールフェデレーションでは、ホスト側とリモート側という表現をしますが、ホストはブラウザが最初に読み込むメインの画面のことで、リモートは、include されるマイクロ化されたフロントモジュールです。
include と言ってるのは、静的にパッケージするのではなく、動的 include です。内部的には、 `<script src=”https://micro.example.com/user-service/v1.0/bundle.js“></script>` このようなコードが動的に生成されるみたいです。

ホスト側では、リモートのモジュールで発生したイベントをフックすることができるので、インターセプターのようなことができます。つまり、マイクロフロントエンドも、プラグインによる機能への介入ができるということになります。再利用性と拡張性が高くなります。

設計パターンとしては、マイクロサービスとマイクロフロントエンドとが必ずしも対になるわけではなく、おそらく、マイクロ化するモジュール単位は、サーバーサイドとフロントエンドでは異なると思います。それをうまく統合するのが、 GraphQL Federation ですが、このインターフェース設計は、とても重要で要になるのだろうと思います。

サーバーサイドもフロントエンドも小さく小さく開発できそうなことが、見えてきました。
システム構成をうまく考えると、ちょっとしたプラットフォームにもなりそうです。

The post マイクロフロントエンド first appeared on 株式会社Altus-Five.

マイクロサービスでAPIが供給されているとして、異なるマイクロサービスが複数あるときに、まるでテーブル結合するかのように、マージしてくれるもの。
クエリーだけじゃなくて、更新系もうまいこと、処理してくれる。

主要なプロダクト

Apollo Federation と WunderGraph Cosmo、GraphQL Fusion などがある。
Apollo が GraphQL Federation のデファクトスタンダートで一番導入実績があり、WunderGraph Cosmoは、最近の導入実績が急激に増えているものらしい。
Apolloは、有料版じゃないと使えない機能があったりするが、Cosmoは、全機能が利用可能で、且つ、Apolloと互換性のあるI/F仕様になっているという安心感が、その理由のようだ。
さらに、Cosmo は AWS Lambda 用に最適化されたコンポーネントがありサーバーレス化が可能なので、小規模なサービスには、持ってこいである。

マイクロサービスアーキテクチャとの親和性

マイクロサービスでは、サービスを超えてDBを共有することはせずに、専用のDBで設計する。
会員管理はRDBを使い、予約管理は DynamoDBを使うということも可能になる。

GraphQL Federation を使って、複数サービスをマージするとして、1つ1つのマイクロサービスは、小さくてシンプルなので、開発しやすい。
その一方で、フロンエンドの実装は、やや、面倒そうではある。

自社プロジェクトでの検証

自社プロダクトである「貸会議室予約管理システム」は、当初は、モノリシックに構築しようと思ったが、マイクロサービス化を推し進めることにした。
懸念されることは、マイクロサービスとして切り出したり、マイクロサービス間の整合性に頭を使わないといけないので、生産性が低下しそうなこと。
だが、それ以上に、マイクロサービスでシステムを構成することのノウハウは、AI時代だからこそ財産になると思うので、学びを優先することにした。

貸会議室の予約管理システムをマイクロサービスにすると、ユーザー管理、会員管理、リソース管理、予約管理、各種通知、・・・、単純に考えても、これだけのマイクロサービスが切り出せる。
これは、再利用できるアセットのバリエーションが増えるということでもある。
モノリシックに作り込んでしまうと、「貸会議室予約管理システム」がたった1つのアセットなので、例えば、「営業支援システム」のような開発をするときにも、「貸会議室予約管理システム」からユーザー管理機能だけを抜き出すのが面倒で、またもや「営業支援システム」用のユーザー管理機能を作り込んでしまう。ほとんど同じなのに。
それが、マイクロサービスになっていると、ユーザー管理マイクロサービスがDockerコンテナで動く状態なので、ユーザー管理機能を新たに作るという動機は起こらず、そのまま再利用する流れになる。

システムを細かくマイクロサービスで設計するときの切り札となるのが、複数サービスの Federation なので、まずは、WunderGraph Cosmo で開発を進めながら、同時に検証してみようと思う。最終的に、やっぱり Apollo に落ち着いたということになるかもしれないが。

The post GraphQL Federation とマイクロサービス first appeared on 株式会社Altus-Five.