graphql-rdb-mismatch

Transcript

1. GraphQLと RDBのインピーダンスミスマッチ 社内 LT会 2024年 6月
2. 今日はこの記事につ いて話します
3. この記事を読んでこう思いませんでしたか？
5. 課題感についてよくわからないという方が多かったのではないかと思い 今回はこの記事に書いた課題感について話します
6. この記事で伝えたいこと 1. RDBのテーブル設計と GraphQLのスキーマは一致しない（ことが多い） 2. どちらかに合わせると良くない 3. インピーダンスミスマッチを解消するには、 Viewが便利 今回は省略
7. RDBのテーブル設計と GraphQLのスキーマは一致しない（ことが多い） RDB GraphQL
8. RDBの正規化は崩したくない。 。 。 じゃあ GraphQLのスキーマを テーブルの構造と一緒にしちゃえばいいじゃん！
9. 実際にそういうフレームワークは結構ある Hasura AppSync Redwood.jsも元々の発想はそうかも
10. 何が悪いの？
11. どちらかに合わせると良くない モデルのネストは DataLoaderを使っても 1+1クエリになる クライアント側で深いネストのオブジェクトでコードが煩雑になる クライアント側は正規化された構造に関心がない
12. 1+1クエリになる こういうクエリがある時 query { users { id name posts { id title } } }
13. 1+1クエリになる usersに紐づく postsを取得するには、下のようなクエリがそれぞれ発行される -- まずusersを取得 SELECT * FROM users; -- usersのidを使ってpostsを取得 SELECT * FROM posts WHERE user_id in ({user_ids}); 2回 RDBに問い合わせすることになる
14. つまりネストするたびに RDBへの問い合わせが増える 正規化されたテーブル構造をそのまま GraphQLに露出すると、経由するテーブルの数だけモ デルをネストすることになる
15. そもそもネストが深いオブジェクトをフロントエンドに押しつけたくな い イミュータブルなモデルそのまま露出するとこんな感じになる type UserResponse = { id: string; latestName: { name: string; // 変更履歴を残してるからテーブルが別 } posts: { id: string; latestTitle: { title: string; // 変更履歴を残してるからテーブルが別 } comments: { id: string; latestComment: { body: string; // 変更履歴を残してるからテーブルが別 } ...
16. 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
17. モデルのネストは少ないほうがいいよね？ じゃあどうする？
19. ご清聴ありがとうございました