GraphQLとREST APIと意味的結合
NTTデータ テクノロジーカンファレンス2020にて、「DX実践!~ビジネスアジリティ向上とマイクロサービス技術GraphQLの活用~」を視聴しました。こういうお話が無料で誰でもお聞きできるのは素晴らしい取り組みだと思います!
経産省資料のDXのキーテクノロジーに「マイクロサービス」というのも、言いたいことがありますが、これは本セッションの本筋ではないので、別の機会に任せることにして…
セッションの中で、GraphQLと比較したREST APIの欠点として、親子構造をもったデータを取得するのに、「親リソースにアクセスして、子リソースにアクセスして、さらに孫リソースにアクセスして…」というAPIをたくさん呼び出し複雑な処理が必要だ、というものを挙げられていました。これは、REST APIのエンドポイントで子、孫リソースも含めて返すように設計すればよいだけで、フェアではない比較になっています。
現状ではGraphQLは、クエリの仕様を従来Producerが提供していたものを、Consumer側にシフトするものであって、責務配置をそうしたい場合に採用すべきアーキテクチャと言え、さもREST APIの上位互換のように語るのは扇動的に感じます。
さらには、GraphQLはシングルエンドポイントになるので、開発競合してアジリティを下げてしまう。でもApolloのフェデレーションを使えば、各サービスの提供するGraphQLをアグリゲーションしてくれるのでOKよ、というニュアンスの話がありました。これも結合度のうち、Provider側のDevelopment Couplingを下げる話だけしかしておらず、これらのサービスを使うConsumer側はどういうタイミングで修正加えるのか? 意味的結合が残る限り、Provider間でも同期とって修正することになるんじゃないの? とかアジリティ下げる要素がまだまだ山積されている状態で、かのような言い回しは危険だと感じました。 Consumer側の使いみちや業務要件まで考慮にいれて、どういう場合にREST APIではなくGraphQLを適用する嬉しいことがあるのか? という方向に、今日のお話されていたプロジェクトが進んでいかれると良いなと思いました。