GraphQLと RDBのインピーダンスミスマッチ 社内 LT会 2024年 6月 

今日はこの記事につ いて話します 

この記事を読んでこう思いませんでしたか？ 

No content

課題感についてよくわからないという方が多かったのではないかと思い 今回はこの記事に書いた課題感について話します 

この記事で伝えたいこと 1. RDBのテーブル設計と GraphQLのスキーマは一致しない（ことが多い） 2. どちらかに合わせると良くない 3. インピーダンスミスマッチを解消するには、 Viewが便利 今回は省略 

RDBのテーブル設計と GraphQLのスキーマは一致しない（ことが多い） RDB GraphQL 

RDBの正規化は崩したくない。 。 。 じゃあ GraphQLのスキーマを テーブルの構造と一緒にしちゃえばいいじゃん！ 

実際にそういうフレームワークは結構ある Hasura AppSync Redwood.jsも元々の発想はそうかも 

何が悪いの？ 

どちらかに合わせると良くない モデルのネストは DataLoaderを使っても 1+1クエリになる クライアント側で深いネストのオブジェクトでコードが煩雑になる クライアント側は正規化された構造に関心がない 

1+1クエリになる こういうクエリがある時 query { users { id name posts { id title } } } 

1+1クエリになる usersに紐づく postsを取得するには、下のようなクエリがそれぞれ発行される -- まずusersを取得 SELECT * FROM users; -- usersのidを使ってpostsを取得 SELECT * FROM posts WHERE user_id in ({user_ids}); 2回 RDBに問い合わせすることになる 

つまりネストするたびに RDBへの問い合わせが増える 正規化されたテーブル構造をそのまま GraphQLに露出すると、経由するテーブルの数だけモ デルをネストすることになる 

そもそもネストが深いオブジェクトをフロントエンドに押しつけたくな い イミュータブルなモデルそのまま露出するとこんな感じになる type UserResponse = { id: string; latestName: { name: string; // 変更履歴を残してるからテーブルが別 } posts: { id: string; latestTitle: { title: string; // 変更履歴を残してるからテーブルが別 } comments: { id: string; latestComment: { body: string; // 変更履歴を残してるからテーブルが別 } ... 

GraphQLはクライアント中心の API As we saw in the introduction, GraphQL is a client-centric API. This philosophy affects how we should design our GraphQL APIs too. While it's tempting to be designing APIs in terms of backend resources or entities, it's very important to design GraphQL APIs with client use cases in mind first, before anything else. (序章で見たように、 )GraphQLはクライアント中心の APIである。この哲学は私たちが GraphQL APIをどのように設計すべきかにも影響を与える。 APIの設計はバックエンドのリソ ースやエンティティを元に実装される誘惑に駆られるが、最初に GraphQL APIクライアント のユースケースを考慮して設計することが重要である。 Production Ready GraphQL (P.24 GraphQL Schema Design: Client first) - Marc-André Giroux 

モデルのネストは少ないほうがいいよね？ じゃあどうする？ 

No content

ご清聴ありがとうございました