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

by Mikio Fujita

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 マンガノについて

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7 GraphQLについて

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

タグ機能について 21

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

41 まとめ

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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