- Java読書会の自分メモ
- せっかく勉強したのにつぎつぎと忘れておくので、印象に残ったところでも記録していく
8.3.3 GraphQL を使った API ゲートウェイの実装
- API GatewayをGraph QLで実現する話
- クライアント側でqueryの内容を変えられるので、graph qlのエンドポイントを一つ作るだけで様々な用途に対応できる
- rest apiだと、多少はパラメータ化できるものの、普通はいくつものapiをつくることになる
- GraphQL スキーマ
type Query {
orders(consumerId : Int): [Order]
order(orderId : Int): Order
consumer(consumerId : Int): Consumer
}
type Order {
orderId: ID,
consumerId : Int,
consumer: Consumer
restaurant: Restaurant
deliveryInfo : DeliveryInfo
...
}
- エンドポイントのところでtype Queryで定義されたクエリーを投げられる
- エンドポイントがリクエストを受けたあとは、バックエンドのマイクロサービス群に、必要なクエリーを発行して、情報をあつめてレスポンスを返す
- この例では、Order、Consumer、Restaurant、DeliveryInfoはそれぞれ別のマイクロサービスが担当している
- node.jsのApollo GraphQLというExpress上で動かせるフレームワークでの実装例が書いてある
9.1.2 マイクロサービスをテストすることの難しさ
- マイクロサービスに分けても、マクロサービス間の依存関係をテストでどう解決するか？
- コンシューマ駆動契約テストパターン
- 呼び出し側のテスト用のスタブと、呼ばれ側のドライバコードを両方生成するうまいやり方。
- まず呼び出し側が期待する「契約（Contract）」を宣言する
- 以下の例は呼ばれた側が、requestに対して、どのようなresponseを返すかを、呼ぶ側の視点で宣言する
- ここから2つのコードが生成される
- スタブ：呼び出し側のテストに使える
- ドライバ：呼ばれ側を実際に呼び出すのに使える
Contract.make {
request {
method ’GET’
url ’/orders/1223232’
}
response {
status 200
headers {
header(’Content-Type’: ’application/json;charset=UTF-8’)
}
body("{ ... }")
}
}
-
以下の順番でプロセスを回す
- 契約を宣言する（上記）
- 呼ばれ側が、ドライバコードを生成・実行し、契約を処理できることを保証する
- 呼び出し側が、スタブコードを使って自身のテストコードを記述する
-
個人的感想
- 想定される呼び出し例を最初に宣言することで、呼び出し側・呼ばれ側双方のテストにつかうのはうまいやり方
- 現実的には複数回の呼び出しがあった場合、呼び出し間の依存関係があって、固定値をリターンするだけではテストにならない
- そのあたりを解決しつつ効率的にテストを書いていけるかが課題と思われる。