Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GraphQLを使い続けて気づいたこと ~Hatena Engineer Seminar #21~

Mikio Fujita
September 08, 2022

GraphQLを使い続けて気づいたこと ~Hatena Engineer Seminar #21~

Hatena Engineer Seminar #21 GraphQL 活用編 での発表資料です。
https://hatena.connpass.com/event/258042/

Mikio Fujita

September 08, 2022
Tweet

More Decks by Mikio Fujita

Other Decks in Technology

Transcript

  1. GraphQLを
    使い続けて気づいたこと
    〜マンガノでの活用事例から〜
    id:miki_bene
    Hatena Engineer Seminar #21 2022/09/07
    1

    View Slide

  2. 自己紹介
    ● id:miki_bene
    ● マンガ投稿チーム
    ● Webアプリケーションエンジニア
    ○ マンガノ / ジャンプルーキー! / あしたのヤングジャンプ
    2

    View Slide

  3. 今日の発表
    ● マンガ投稿チームで開発している
    マンガノというサービスの話
    ● 開発の当初からGraphQLを使っている
    ○ 約2年ほどになる
    ● GraphQLについて
    開発を続けて気づいた点を紹介
    3

    View Slide

  4. ● マンガノについて
    ● GraphQLについて
    ● GraphQLの開発を続けて気づいたこと
    ● まとめ
    4
    今日の発表

    View Slide

  5. 5
    マンガノについて

    View Slide

  6. マンガノについて
    6
    ● はてなと株式会社集英社の少年
    ジャンプ+編集部が協業し提供す
    るマンガ投稿サービス
    ● 2021/04よりサービス開始
    ● 作品の販売機能 / 様々なWEBマ
    ンガ公開プラットフォームのURL
    を整理・公開できるポートフォリ
    オ機能など

    View Slide

  7. 7
    GraphQLについて

    View Slide

  8. GraphQL について
    ● API向けのクエリ言語
    ● サーバーで取得可能なリソースをスキーマ定義
    ● クライアントはほしいデータのクエリを書き取得
    8

    View Slide

  9. GraphQL について
    9
    スキーマ クエリ 取得できるデータ

    View Slide

  10. GraphQL の特徴
    ● 公式サイトによると
    ○ クライアントがほしいデータだけを返せる
    ○ 1回のリクエストで様々なデータを返せる
    ○ 強力な開発者ツール
    ○ etc…
    10

    View Slide

  11. 11
    GraphQLの開発を続けて
    気づいたこと

    View Slide

  12. 開発を続けて気づいたこと
    GraphQLのスキーマ設計によって、
    フロントエンド - バックエンドの両方にとって
    無理のない実装が可能になっている
    12

    View Slide

  13. 無理のない実装が可能
    フロントエンド - バックエンドの実装上の都合を、
    片方に押し付け合わないで済む
    13

    View Slide

  14. フロントエンドの実装上の都合
    14
    ● フロントエンドの都合
    ○ 1つのAPIから様々なデータがほしい
    ○ 画面に表示する分のデータだけ返してほしい

    View Slide

  15. バックエンドには不都合
    15
    ● これを満たすAPIはバックエンドにとって不都合
    ○ 1つのAPIの処理で様々なデータを集める
    ○ 多くのパラメータを考慮する
    ● バックエンドの実装が複雑になる

    View Slide

  16. バックエンドの実装上の都合
    ● REST APIのように作りたい
    ○ バックエンドの提供するリソースや操作に対して
    エンドポイントを作成
    ○ バックエンドは秩序立ったAPIに
    16

    View Slide

  17. フロントエンドには不都合
    ● フロントエンドにとって不都合
    ○ 表示したいリソースを取得するため、
    何度もAPIリクエストを行う
    ○ 表示しないデータまで取得してしまう
    ● 実装が複雑化・パフォーマンスに影響
    17

    View Slide

  18. 実装上の都合
    ● これまでのAPI開発
    ○ フロントエンド - バックエンドの都合を
    同時に満たすことが難しい
    ○ 片方が不都合な実装になりがち
    18

    View Slide

  19. GraphQLが実装上の都合を解消する
    ● 実装上の都合を解消するGraphQLの特徴
    ○ フロントエンドがほしいデータを返せる
    ○ 1回のリクエストで返せる
    ● フロントエンドは都合を満たせ、バックエ
    ンドは不都合な実装をせずに済む
    19

    View Slide

  20. 20
    タグ機能開発での
    スキーマ設計の例

    View Slide

  21. タグ機能について
    21

    View Slide

  22. タグのタイトルについての仕様
    22
    #Engineer #Engineer
    作品A 作品B
    同じタグと識別されたいので
    テキストを正規化して保持
    =
    システム内

    View Slide

  23. 23
    作品に紐づく形でタグを表示する際は
    ユーザーが元々入力したものを表示
    タグのタイトルについての仕様
    画面表示上
    #Engineer #Engineer
    作品A 作品B

    View Slide

  24. 画面からスキーマを検討
    24
    #タグ1
    作品
    #タグ2 #タグ3
    作品に紐づけられた
    タグを一覧できる

    View Slide

  25. 25
    #タグ
    作品A
    作品B
    作品C
    タグが付いた作品を
    一覧できる
    画面からスキーマを検討

    View Slide

  26. GraphQLスキーマの例
    26
    タグや作品をスキーマで表すとこう

    View Slide

  27. 27
    作品に紐づくタグ一覧 タグを付けた作品一覧
    クエリを書いてみるとこう
    GraphQLスキーマの例

    View Slide

  28. タグの仕様を思い出す
    28
    このtitleのフィールドに
    ユーザーが元々入力した
    タイトルが入る
    作品に紐づく形でタグを表示する際は
    ユーザーが元々入力したものを表示

    View Slide

  29. 29
    作品に紐づく形でタグを表示する際は
    ユーザーが元々入力したものを表示
    ● フロントエンドは返ってきた
    データを表示するだけ
    ● バックエンドは返すデータを
    作品によって出し分ける必要
    があり、やや煩雑
    タグの仕様を思い出す

    View Slide

  30. 30
    作品に紐づく形でタグを表示する際は
    ユーザーが元々入力したものを表示
    ● バックエンド側が
    仕様の都合を背負う形に
    ● できればフロントエンド-
    バックエンドの両方で無理の
    無い形で実装したい
    タグの仕様を思い出す

    View Slide

  31. WorkTag を登場
    31
    作品に紐づくタグを表す WorkTag を登場
    ● DBの中間テーブルのようなType
    ● WorkTag にユーザーが元々入力
    したタイトルを持たせる
    ● Work は Tagの代わりに
    WorkTag の配列を返す

    View Slide

  32. WorkTag を登場
    32
    WorkTag 登場時のクエリ 以前のクエリ ● フロントエンドのクエリは以
    前とほぼ変わらない
    ● バックエンドは中間テーブル
    のデータを出すだけで済む
    フィールドの出し分けが不要
    自然な実装に

    View Slide

  33. 両方無理のない実装が可能に
    ● このようにGraphQLのスキーマ設計によって、
    フロントエンド - バックエンドで無理のない実装
    が可能になった
    ● スキーマ設計時の考慮が効いた
    ○ フロントエンドがほしいデータだけでなく
    ○ バックエンドの実装上の都合も考慮した
    33

    View Slide

  34. GraphQLのお陰で無理ない実装が可能
    ● フロントエンド - バックエンドの実装の詳細から
    一歩引いた立場で設計することになる
    ○ 詳細をそのままスキーマにしない
    ○ 片方の都合によらない
    ■ フロントエンドがほしいデータを返せる
    ■ バックエンドが提供するリソースを表現できる
    34

    View Slide

  35. 35
    スキーマ設計を
    上手く回せている理由

    View Slide

  36. 回せている理由
    1. 開発者がフロントエンド-バックエンド両方担当
    2. 以前からワイヤーフレームを元に開発を開始してきた
    36

    View Slide

  37. フロントエンド-バックエンド両方担当(1/2)
    ● 全員がフロントエンド-バックエンド両方を担当
    ○ 画面でほしいリソースを理解
    ○ バックエンドの実装や都合にも通じている
    ● スキーマを設計する際も、
    自然と両方の都合を考慮できている
    37

    View Slide

  38. フロントエンド-バックエンド両方担当(2/2)
    38
    ● マンガ投稿チームでは全員でスキーマ設計を行う
    ○ スキルやドメイン知識を補完し合える
    ● よりよいスキーマ設計に繋がる

    View Slide

  39. ワイヤーフレームを元に開発開始 (1/2)
    ● マンガ投稿チームでは、ワイヤーフレームを元に機能開
    発を開始するのが主流
    ○ JSON API / テンプレートエンジンでHTMLを返す
    ● GraphQLでも自然とワイヤーフレームを元にスキーマ設
    計が出来た
    ○ ワイヤーフレーム=>リソース検討=>スキーマ設計
    39

    View Slide

  40. ● ユーザーが見るものから検討を始める
    ○ GraphQLに限った話ではない
    ○ JSON API / テンプレートエンジンのときもそうだった
    ○ GraphQLよりも良い技術が出てきても適応できるだろう
    40
    ワイヤーフレームを元に開発開始 (2/2)

    View Slide

  41. 41
    まとめ

    View Slide

  42. まとめ
    ● GraphQLのスキーマ設計によって、
    フロントエンド-バックエンドの両方にとって
    いいバランスで実装が可能
    ● マンガ投稿チームでは上手くスキーマ設計が出来
    ている
    ○ 開発者がフロントエンド-バックエンド両方の開発を担当
    ○ ワイヤーフレームを元に開発を開始
    42

    View Slide

  43. GraphQL API を採用してわかったこと
    ● APIの実装で困ったことはほぼ無く、
    それ以外の課題にフォーカスできている
    ● フロントエンドだけでなく、
    バックエンドの開発にとってもメリットがある
    43

    View Slide