単一のエンドポイントで、クライアント側で指定することで任意のデータを取得できるGraphQLですが、ビジネスで利用する際に必ず注意しなければならないのがセキュリティでしょう。GraphQLを利用、提供する上での注意点を紹介します。
認証
GraphQLではサーバサイドのデータベースのようにID/パスワードのような仕組みは用意されていません。他のAPIと同様に、認証技術と組み合わせることができます。例えばOAuth2であったり、トークン認証になります。これらは自分で実装する必要があります。
そのため、REST APIとGraphQLの共存は難しいことではありません。取得（GET）についてはGraphQLを、データの追加/更新/削除はREST APIといった具合に使い分けることもできます。その際、どちらも同じ認証データを用いられるでしょう。
ネスト
GraphQL特有の問題として、関連データのネストがあります。Eコマースなどにおいて、あるユーザが複数の注文履歴情報を持ち、個々の注文履歴は複数の商品データを持ちます。さらに個々の商品データは複数の在庫情報を持つかも知れません。そうした関連データを連結して取得できるのもGraphQLの特性ですが、あまり深くネストを指定できる訳ではありません。サーバ側の設定で変更できますが、デフォルトで2つまでというのが多いようです。
GraphQLはインタフェースであって、その背後にあるのは従来のデータベースになります。SQLで関連テーブルをつなげていくと、負荷が増してしまうのは当然です。運用時には注意が必要でしょう。
バリデーション
GraphQLでは元々スキーマを定義してクエリを受け付けます。そのため、数値や文字列などのレベルにおいてはデフォルトで入力チェックが行われます。しかし文字列長であったり、メールアドレスやユーザIDのユニークチェック、パスワード検証のような仕組みは用意されていません。そういった特定のフローについては自分で実装しなければなりません。
とは言え、一度スキーマレベルでのチェックを通っていることで、サーバサイドでの実装はシンプルなものになるでしょう。
権限
GraphQLはスキーマが一つしかありません。そのため、ユーザ/グループごとにアクセスさせたいデータ、させたくないというデータがあるとコードですべて実装しなければなりません。この実装はかなり煩雑になる上、スキーマ上は構造が確認できる形になるでしょう。
そしてユーザが記述したGraphQLのクエリに対して、アクセスしていいデータかどうかを判別するというのはかなり煩雑な処理になるでしょう。今の時点では良い解決策がなさそう（権限毎にGraphQLのパスを分けるなど）なので、GraphQLは全体に対して共通仕様であると考えた方が良さそうです。
GraphQLはまだ新しい技術だけに、すべての仕様をきちんと把握した上で運用するようにしないと思わぬトラブルにつながる可能性があります。既存のREST APIとの棲み分けや、利用範囲の絞り込みなどを行った上で運用した方が良さそうです。
