GraphQL（スキーマ設計）素振り

島袋恵

参考記事っ！！！！

島袋恵

定義したもの

島袋恵

スキーマ考える時系列

GitHubのAPI のdocsを眺める
implements Node する考え方を知る
再び GitHubのAPI のdocsを眺める
Node以外もGraphqの途中でいろんなObjectsがimplementsされてることに気が付く（裏側の実装どうなってるんだろう！？！？！？めっちゃむずそう〜〜〜〜ってなる）
DBのスキーマを見ながらGraphQLのスキーマを定義しはじめる
テーブル構造が露見した感じのAPIだとよくないよねとか、Root Query 直下にたくさん Query書いちゃうのRESTっぽい感じになるよねとか、ログインユーザーを起点にしてクエリ叩いてデータ引けるようにしたほうがGraphQLっぽさそうだよね、みたいな話をしながらいろいろ調べたりした
Userを起点にグラフの構造を考えはじめる
途中、何度か「初めてのGraphQL」本を開いてキャッチアップなどする
中間テーブル、いくつかのテーブルから参照されてるテーブル構造になってるやつで、どうやって値取得したらいいか（どうスキーマで表現したらいいか）よくわからないやつで少し悩みつつ、いったん全部定義する

島袋恵

GitHubのAPI のdocsを眺める

参考クエリ

{
  repository(owner: "rails", name: "rails") {
    name
    defaultBranchRef {
      target {
        ... on Commit {
          history(first: 10) {
            pageInfo {
              hasNextPage
            }
            edges {
              node {
                oid
                message
                messageHeadline
                author {
                  name
                  email
                }
              }
            }
          }
        }
      }
    }
  }
}

島袋恵

implements Node する考え方を知る

interface Node {
  id: ID!
}

type Query {
  node(id: ID!): Node
}

島袋恵

再び GitHubのAPI のdocsを眺める → Node以外もGraphqの途中でいろんなObjectsがimplementsされてることに気が付く（裏側の実装どうなってるんだろう！？！？！？めっちゃむずそう〜〜〜〜ってなる）

この Commit どこから湧いてきたやつか一瞬謎だったけどImlementsされてるやつだった。クライアントからGraphQL使う分だとdocsみて、ぽちぽちクエリ書いて便利って気持ちだったけど、バックエンド側でグラフ構造作るのって、全体のデータ構造把握して、いい感じにグラフ構造作らなきゃいけなくて、めっちゃむずでは！？！？！と思ったりした