Skip to content

Latest commit

 

History

History
175 lines (150 loc) · 3.77 KB

README.md

File metadata and controls

175 lines (150 loc) · 3.77 KB

GraphQLを触ってみた

会社でGraphQLを検証することになったので、一旦どのようなものか理解するため軽く触ります。

DBの構造と発行するクエリに差分があった方が、GraphQLのテストとして良いなと思ったので木構造を触ることにしました。 閉包テーブル（closure table）を扱うgemであるclosure_tree を利用しました。 以下のような組織図を表すデータをseedに入れています。(closure_treeから書き出しもできて便利でした。)

table

見どころ

app/graphql/types/query_type.rb

飛んできたクエリをハンドリングしてるところです。

つまづきどころ

apimodeで作ったため、GraphQLのエディタを出すために、application.rb をいじっています。

一応使い方

bin/bundle install

bin/rails db:create
bin/rails db:migrate
bin/rails db:seed

bin/rails server
open http://127.0.0.1:3000/graphide # ここで色々とqueryが書けて便利

実際のクエリと結果

Case1

Query

{
  rootOrganizations {
    id
    name
  }
}

Result

{
  "data": {
    "rootOrganizations": [
      {
        "id": "1",
        "name": "経営会議"
      },
      {
        "id": "14",
        "name": "z_club_スノボ"
      }
    ]
  }
}

Case2

Query

{
  children(parentId: 2) {
    id
    name
    parent {
      id
      name
      parent {
        id
        name
        children{
          id
          name
  	    }
      }
    }
  }
}

Result

{
  "data": {
    "children": [
      {
        "id": "3",
        "name": "マッチング領域",
        "parent": {
          "id": "2",
          "name": "プロダクト部",
          "parent": {
            "id": "1",
            "name": "経営会議",
            "children": [
              {
                "id": "2",
                "name": "プロダクト部"
              },
              {
                "id": "11",
                "name": "カスタマーサポート"
              }
            ]
          }
        }
      },
      {
        "id": "7",
        "name": "スポットワークシステム領域",
        "parent": {
          "id": "2",
          "name": "プロダクト部",
          "parent": {
            "id": "1",
            "name": "経営会議",
            "children": [
              {
                "id": "2",
                "name": "プロダクト部"
              },
              {
                "id": "11",
                "name": "カスタマーサポート"
              }
            ]
          }
        }
      },
      {
        "id": "10",
        "name": "コーポレートIT",
        "parent": {
          "id": "2",
          "name": "プロダクト部",
          "parent": {
            "id": "1",
            "name": "経営会議",
            "children": [
              {
                "id": "2",
                "name": "プロダクト部"
              },
              {
                "id": "11",
                "name": "カスタマーサポート"
              }
            ]
          }
        }
      }
    ]
  }
}

感想など

  • 結構柔軟に扱えて良さそう。特にフロントエンドにUsercaseを寄せられそうで良さそう。
  • ファイルのスコープや名前空間に関しては結構気をつけた方が良さそう。Resolverを分けることで一定認知負荷は減らせそう。
    • 必要に応じて、実は複数エンドポイント作った方がいいかもしれない(?)
  • 名前空間の議論は面白そうなので読む