Scala勉強会での発表資料

1. ScalaでGraphQL
芸者東京
竹下義晃

2. GraphQLとは
https://graphql.org/learn/
クライアント <-> サーバー間のリクエストを行うためのク
エリ言語仕様
Facebookが開発。githubも採用

3. GraphQLとは
Schema Query
type Query {
user (id : Long!): User
}
type User {
id: Long!
nickname: String!
friends: [User!]!
}
query {
user(id: 1) {
id
nickname
friends {
nickname
friends {
nickname
}
}
}
}
Schemaを定義して、サーバーとクライアントで共有
Queryで取得したいフィールドをだけを指定して取得
Schema,Queryは独自文法、結果はjson(が普通)
結果
{
“data”: {
“id”: 1,
“nickname”: “Hoge”,
“friends”: [{
“nickname”: “Fuga,
“friends”: [{
“nickname”:”foo”
}, ...]
}, …]
}
}

4. メリット
● 複数のリクエストを一つにまとめられる
● サーバーとクライアントの実装をGraphQLで分断できる
● 様々なツール、ライブラリのサポートを受けられる
デメリット
● パフォーマンスを出すための暗黙の知識が結構必要
● まだ普及仕切っていないので使える人は限られる

5. 複数のリクエストを1つにまとめられる
query getUserAndNews{
user(id: 1) {
nickname
}
news(size: 20) {
title
body
}
}
Restだと2つのAPIを呼び出す(かわざわざ2つの機能を合体させた新しいEndpointを作
る)必要があるような呼び出しを、クエリを書き換えるだけでまとめて呼び出せる
ただ、Http2が普及すれば、このメリットはほぼ無くなる。よくメリットとして上げられるが、
割とどうでもいいと思っている

6. サーバーとクライアントの実装を分断できる
Schemaを共有することで、サーバーができていなくても事前にクライアントの実装がで
きる。また、細かな仕様変更もクライアント側でQueryを修正するだけで対応できる
ただのRestAPI
API仕様策定 -> サーバー実装 -> 修正
-> クライアント実装 -> 接続試す -> 修正
(サーバー、クライアント共に実装完了しないとテストが困難)
GraphQL
API仕様策定 -> サーバー実装 -> 適当なQuery投げてテスト
-> クライアント実装 -> 投げるQuerySchemaに合うかチェック -> 接続試す

7. 様々なツール、ライブラリのサポートを受けられる
標準化されていることで、対応したツール、ライブラリを使用できるのでいろいろらくでき
る
# GraphiQL
Queryを書いて、投げて、結果を見れるツール。Queryの保管もやってくれる
# 各言語ライブラリ
Schema,Queryのパースや組み立てをやってくれる

8. デメリット
# パフォーマンスを出すための暗黙の知識が結構必要
これはRestAPIだとしてもあり得るのでそこまでデメリットではないが、やはり特有の最
適化知識は必要になってきそう
# まだ普及仕切っていないので使える人は限られる
即使えますって人はまだあまりいないと思います。啓蒙必要

9. Scalaでは？
Sangria( https://sangria-graphql.org/ )
というライブラリがある。サーバー/クライアントどちらにも使用可能
機能は大体ドキュメントとサンプルみればわかる
機能
Query
● DSLによるQuery構築
● テキストからのQueryのパース
● Schema検証
● Queryの実行
Schema
● DSLによるSchema構築
● AnnotationベースによるDSL自動生成
● テキストからのSchemaのパース

10. 自分で書きたく無い機能群
# Introspectionの機能
Schemaの情報を返す機能。勝手にサポートしてくれる
# やばいクエリの検証機能
リスト取得時に大きすぎるsize指定や、深すぎるネストをバリデーションして実行時に弾
く機能がある
# N+1問題の対応機能
(すごく使いやすいわけでは無いが)内部で複数のDBアクセスをまとめて1回の実行にす
ることのできる汎用機構がある

11. 余談
GraphQLを使うとリクエストがqueryとmutationに分離されるので、
CQRS( https://docs.microsoft.com/ja-jp/azure/architecture/patterns/cqrs )
の設計パターンと親和性が高いのでは？