GraphQLは内部API向きか外部API向きか
「内部API向きだ・外部API向きではない」という意見があって、論点は以下のようなものです
API呼び出し制限が難しく、複雑なクエリを許してしまう
⇢ graphql-ruby はfieldごとにcomplexityを設定して制御できます
リクエスト中の情報が多いので、制御はむしろやりやすいです
GraphQL自体にはアクセス制限機構がないので実装コストが高い
⇢ graphql-guard gemというauthorization用のpluginがあります
「外部API向きだ・内部API向きではない」という意見もあって、これは主に以下のような論点のようです
API serverの実装コストが高いので内部APIとしては高コスト
スキーマがないような素朴なRESTful APIと比較すると確かに高コストかもしれません
Schema-Driven Development するなら大差ないと思っています
SDDする場合、ライブラリの品質にかなり影響をうけるので一概には比較できない気もします
micro servicesの文脈ではgRPCと比較してメリットがないように見える
gRPCはRPCなので、「重いフィールドを必要なければ取ってこない」ためにプロシージャを一つ余計に定義する必要があります
GraphQLは必要なフィールドのみを取得するので、typeの定義は1つで済みます
また、1画面を構成するのに必要なリソース取得を1 queryにまとめることで、内部でRDBMSへのSQLクエリを最適化できます
⇢ graphql-batch
一方で、GraphQLはtransport layerについて規定がないので、双方向通信（i.e. subscriptions）のためにがんばりが必要です
AWS AppSync は GraphQL over MQTT (over Websocket) でがんばってるみたいですね
#FAQ