「GraphQL?なにそれ？」
私も知らなかったGraphQLという単語。これはRestAPIの次の世代のAPIとしてFacebookで開発された言語らしく、リリースされてからまだ数年しか経っていない新しい技術です。そのためか、まだまとまったドキュメントはなく、WEBを見ても？となる時間が多い技術だったりします。
そこで、今回は「なぜGraphQL？」という疑問を解決する３つのメリットを紹介します。
目次
メリット１ NoSQLスキーマで開発でき、APIが自動デプロイされる（DynamoDB + AppSync）
NoSQLデータベースの最大のメリット「スキーマが柔軟にできる」（逆にいうと、統率がとれない）を享受できるのが、GraphQLの一つではないでしょうか。
GraphQLはコードでAPIを定義し、AppSyncにアップロードする事で簡単なDynamoDBへのI/Oのコードを自動生成してくれます。
具体的には、
・LaravelなどにあるModel(Laravelのドキュメント)を作成する（Model名とテーブル名を決める）
・その定義をアップロードするとmutationとqueries、DynamoDBのテーブルを自動的にAWSが生成する
・CRUD操作が使用できるようになる
という流れになります。本当に便利！
ただし、現在のAWSチュートリアルには「Cognitoでの認証方法は？」「もともとあったAPI Gatewayとの違いは？」という事がそこまで触れられておらず、ちょっと内容を把握するのに時間がかかりました。
結論から言うと、AppSyncはAPI gatewayと関係ありません。GraphQLはAppSyncのみの機能です。
また、コード生成にはAWS Amplifyというライブラリを使用するのがベスト・プラクティスだと感じます（GUIで操作をすると痛い目を見るので、必ずCLIで操作する必要ありますが。この意味が分からない人はまずCLIでできる開発を一度経験するとおおよそ感覚が掴めます）
メリット２ 入れ子構造のAPIを組めるようになる(Restでもできるけどね！）
メリットの２つ目には、入れ子式でAPIが組める、と言う事をあげたいと思います。入れ子式？Restfulでもできるじゃん？と言うかたもいるかと思いますが、メリット１と同じく「子供にもデータModelを適応してModelの親子関係を定義したかたちでのAPIが定義できる」のがメリットです。
例えば、学年と言うModelとクラスと言うModelがあったとします。この時、学年と言うModelの下にクラスと言うModelがあります。すると、以下のようなデータ定義が生まれると思います。
学年：入学年度、学年主任、学校名
クラス：担任名、人数、学力平均
この時、クラスのModelにある担任が佐藤となっているデータ、を引き抜きたい場合、人数が４０人以上のクラスを引き抜きたい場合、学力平均が何点以上…といったかたちで、引き抜きたいものに応じてAPIを複数作って引き抜くかたちが多いと思います。
しかし、GraphQLを使うと、任意の項目に対して柔軟にFilter式が適用されるので、GraphQLのAPIが一つあればデータ検索、抽出ができるようになります。またそれぞれに対してCRUD処理が自動的にAPIとして作成されるので、Modelの定義＋APIが一つのAPI（データモデル）の定義で済むということになります。書き方には少々癖があるのですが、それさえクリアできればGraphQLを使用することでAPIのメンテナンスコストを大幅に下げることができます。
メリット３ ドキュメント生成コストが圧倒的に下がる
ドキュメントを作成せずとも、APIサンプル(Model定義)を提供することで誰もがすぐに使えるシステムを作ることができます。またAPIを複数作成する必要がないので、開発時間を下げることがきっとできるはずです。
ところで、こんなGraphQLのメリットがあるにも関わらず、私の場合はとても多くの時間をGraphQLを使用した開発に当てることとなってしまいました。。原因としては
・とてもじゃないけど一人で悩んで理解するものではなかった（時間がかかりすぎました）
・それぞれのAWSリソースの関連性が分からず苦戦した
というのがあげられます。
次回以降の記事では、実際にAppSync(AWS Amplify)を使用して個人で開発した時につまづいたこと、素人目線で見たときにここでつまづく！と私が個人的に感じたポイントを逐次紹介していきます。
