勘違いやすいこと
-
GraphQLが、OracleDBやPosgreQLなどのRDBMSと勘違いやすいが、実は、Webシステムを外部から利用するためのプログラムの呼び出し規約(API)の種類の一つで、敢えて何かと比較したいであれば、RESTAPIと思います。 -
QLの部分は、勘違い原因ですが、クエリ言語を指すこともできるからです。
GraphQLを学習する価値があるか？
マクロの観点：
学習する内容は、時代に合わせてした方がいいという認識がありました。そして、時代に合わせたものほど、価値が高いという認識です。
そこで、APIの管理方法も変化しつつであり今は、マイクロサービスや、サービスメッシュへ相性のいい言語やツールなどができました。GraphQLは、前期の背景のなかで、新たにできたものと言われています。
ミクロの観点：
2022年でGraphQLを携わったことがあったため、会社の財産として、今後営業してくれる方々が、GraphQLがまだ新しい技術であるうちに、「GraphQLでAPIを管理する実績」があるとアピールできる信じています。
Autodeskなどの企業のAPIは、RESTとGraphQL2通でAPI（のリクエスト・レスポンス）を管理することが多くなるだろう。
現状では、Autodesk Fusion 360がGraphQLを利用したと確認した。
GraphQLを試してForgeを動かせるサンプルもありました。が、あくまでサンプルのようです。
学習すれば、どのぐらいの価値がある？
上記の背景や、AutodeskAPIの動向などで、学習する価値が理解できると思いますが、実は学習しないと、損するのイメージが強いと感じます。
そもそも、GraphQLは何？
ref: GraphQL とは
概要
-
GraphQLは、API向けのクエリ言語とサーバーサイドランタイムの両方を指します。クライアントがリクエストしたデータだけを提供することを優先します。 -
GraphQLは、API の速度、柔軟性、開発者にとっての使いやすさを向上させるために設計されました。GraphiQL と呼ばれる統合開発環境 (IDE) にデプロイすることもできます。GraphQLは REST の代わりに、データを複数のデータソースから取得するリクエストを 1 つの API 呼び出しで構成できます。 -
さらに、
GraphQLによって、既存のクエリに影響を与えずに、フィールドの追加または廃止を柔軟に保守できます。開発者は API をどんな方法で構築しても構いません。構築された API はGraphQLの仕様によって、クライアントに予測可能な方法で動作します。
Pros
-
GraphQLスキーマはGraphQLアプリケーションに単一のソースを設定します。 - 組織には API 全体をフェデレーションする方法が提供されます。
-
GraphQL呼び出しは 1 回のラウンドトリップで処理されます。 - クライアントはリクエストしたものを取得し、余分なものは取得されません。
- データ型はしっかり定義されているので、クライアントとサーバー間の食い違いが減少します。
-
GraphQLはイントロスペクションが可能で、クライアントは、利用できるデータ型のリストを- リクエストできます。これは自動生成文書に最適です。 -
GraphQLでは、既存のクエリを壊さずにアプリケーション API を進化させることができます。 - 多数のオープンソース
GraphQL拡張機能が利用可能で、REST API にはない機能を提供しています。 -
GraphQLは特定のアプリケーション・アーキテクチャにとらわれません。 - 既存の REST API 上に導入して、既存の API 管理ツールと連携できます。
Cons
- REST API に慣れている開発者の場合、
GraphQLを学習する期間が必要になります。 -
GraphQLではデータクエリ処理の多くがサーバーサイドに移行されるので、サーバー開発者の- 作業が複雑になります。 - 実装方法によっては、REST API とは異なる API 管理戦略が必要になります (特に、レート制- 限や価格設定を考慮する場合)。
- キャッシュが REST よりも複雑になります。
- API 保守担当者には、保守可能な
GraphQLスキーマを作成する作業が付加されます。