Web系エンジニアのアウトプット練習場スマートフォン用の表示で見るWeb系エンジニアのアウトプット練習場エンジニアリングと書評が中心。APIとマイクロサービスFederationを使用しない場合Federationを使用する場合まとめはじめに私は現在、仕事でGraphQLを用いてマイクロサービスを構築しております。今回はそこで得られた知見を共有させていただきます。Server」の拡張の1つで、個人的にはGraphQLを用いたマイクロサービスの構築に欠かせない存在であると思っています。マイクロサービスにおいてFederationとは何か?どのように役に立つのか?といったことを、Federationをご存じない方にもご理解いただくことが本投稿の目的です。複数のGraphQLサービスを一つのGraphQLサービスとして提供するための仕組みです。サービスや組織が複雑化するにつれて、モノリシックなGraphQLサーバーでは辛くなってきます。そんなときにFederationを使用すると、モノリシックなGraphQLサービスをマイクロサービスに分割することができます。...とだけ聞いても訳がわからないので、具体例を使って説明していきます。APIとマイクロサービス例えば、Userサービス、Productサービス、Reviewサービスがそれぞれ以下のようなスキーマを提供したいとします。*1また、以下のようにユーザーがGatewayを経由して各サービスに接続する構成を考えます。Federationを使用しない場合まず、Federationを使わない場合を考えます。Userサービスは、あるユーザーが行ったレビュー内容をreviewsフィールドで取得できなければなりません。期待されるクエリとレスポンスの例は以下のようなものとなります。}}このとき、Userサービスはレビュー内容やレビュー対象の製品情報をレスポンスに載せるために、それらの情報をReviewサービスから取得してこなければなりません。結果、Userサービスの実装はReviewサービスの実装に依存することになり、各サービス間での関心の分離ができなくなります。Reviewサービスの実装に何か変更がある際に、常にUserサービスへの影響も考慮しなければならなくなります。上記の例ではReviewサービスやProductサービスも、それぞれ他のサービスに関するフィールドが定義されているため、相互に依存することになります。これではモノリシックに構築していたときのほうがまだマシということになりかねません。Federationです。Federationを使用する場合GatewayにFederationを導入します。以下のようにスキーマを定義します。最初のスキーマと比べてみると、以下のような違いがあります。Productが追加され、それぞれreviewsフィールドが定義されている実はこのextendはFederationで定義されているキーワードの1つで、「関心の分離」を達成するために重要なキーワードの1つです。Productは「実装の詳細はわからないけど、何やら別のサービスにProductというタイプがあるらしい」ということを表しています。Productというフィールドが存在します。以下のようなクエリとレスポンスが期待されます。upc)はReviewサービスが保持していることがほとんどでしょうが、関心の分離の観点からReviewサービスは製品情報の詳細を知りたくはありません。製品情報(nameやprice等)はProductサービスから返したいです。ここで必要になるのが、keyとexternalというディレクティブです。スキーマにkeyとexternalディレクティブを追加します。Int}このように定義し、リゾルバーを書きます。}}ここまで実装した上で、ユーザーが以下のクエリを投げたとします。}}すると、Federationを導入したGatewayは、Reviewサービスからレビューの情報と製品の識別子(upc)を取得するReviewサービスから得られたupcを元にProductサービスから製品情報を得るユーザーのクエリに基づいたレスポンスを構築してユーザーに返すというように、Federation用に定義したスキーマの情報からクエリプランニングを行い、自動的に各サービスに必要な情報を問い合わせてレスポンスを構築してくれます。[Review]というフィールドが定義されています。ここでは、ReviewサービスがProductタイプに「製品に対するレビュー」を返すフィールドを追加するという宣言しています。これに対しても、以下のようにReviewサービスでリゾルバを書きます。}}そして、ユーザーが以下のクエリを投げたとします。}}するとやはり、Gatewayが自動的にクエリプランニングを行い、レスポンスを構築してくれます。Productサービスからレビューの情報以外の情報を得るProductサービスから得られたupcを元にReviewサービスからレビュー情報を得るユーザーのクエリに基づいたレスポンスを構築してユーザーに返すこのように、Federationを使用することで、ReviewサービスはProductタイプの詳細を知ることなく、製品情報を返したり、製品情報にレビュー情報を付け足したりすることが可能になりました。UserサービスやProductサービスについても同様に、各サービスの詳細情報を知ることなく、簡単に担当部分のみ実装することができるため、関心の分離を容易に達成することができます。まとめ本投稿では、Federationを用いたマイクロサービス構築についての知見を共有させていただきました。stitchingという従来の方法(deprecated)からFederationへのマイグレーションを行ったところ、全体の開発速度が大きく向上しました。stitchingではなかなかできなかった「関心の分離」を、Federationではいとも簡単に実現できたからであると推測できます。これからどんどんGraphQLが注目され、マイクロサービスの構築にも採用されてくるのではないかと私は予想しています。Federationという選択肢を検討してみてください。Qiitaの9日目の記事です。月別アーカイブリンクはてなブログブログをはじめる週刊はてなブログはてなブログProはてなブログをはじめよう!h-sakanoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。