Hatena Engineer Seminar #21 GraphQL 活用編 での発表資料です。 https://hatena.connpass.com/event/258042/
GraphQLを使い続けて気づいたこと〜マンガノでの活用事例から〜id:miki_beneHatena Engineer Seminar #21 2022/09/071
View Slide
自己紹介● id:miki_bene● マンガ投稿チーム● Webアプリケーションエンジニア○ マンガノ / ジャンプルーキー！ / あしたのヤングジャンプ2
今日の発表● マンガ投稿チームで開発しているマンガノというサービスの話● 開発の当初からGraphQLを使っている○ 約2年ほどになる● GraphQLについて開発を続けて気づいた点を紹介3
● マンガノについて● GraphQLについて● GraphQLの開発を続けて気づいたこと● まとめ4今日の発表
5マンガノについて
マンガノについて6● はてなと株式会社集英社の少年ジャンプ＋編集部が協業し提供するマンガ投稿サービス● 2021/04よりサービス開始● 作品の販売機能 / 様々なWEBマンガ公開プラットフォームのURLを整理・公開できるポートフォリオ機能など
7GraphQLについて
GraphQL について● API向けのクエリ言語● サーバーで取得可能なリソースをスキーマ定義● クライアントはほしいデータのクエリを書き取得8
GraphQL について9スキーマ クエリ 取得できるデータ
GraphQL の特徴● 公式サイトによると○ クライアントがほしいデータだけを返せる○ 1回のリクエストで様々なデータを返せる○ 強力な開発者ツール○ etc…10
11GraphQLの開発を続けて気づいたこと
開発を続けて気づいたことGraphQLのスキーマ設計によって、フロントエンド - バックエンドの両方にとって無理のない実装が可能になっている12
無理のない実装が可能フロントエンド - バックエンドの実装上の都合を、片方に押し付け合わないで済む13
フロントエンドの実装上の都合14● フロントエンドの都合○ 1つのAPIから様々なデータがほしい○ 画面に表示する分のデータだけ返してほしい
バックエンドには不都合15● これを満たすAPIはバックエンドにとって不都合○ 1つのAPIの処理で様々なデータを集める○ 多くのパラメータを考慮する● バックエンドの実装が複雑になる
バックエンドの実装上の都合● REST APIのように作りたい○ バックエンドの提供するリソースや操作に対してエンドポイントを作成○ バックエンドは秩序立ったAPIに16
フロントエンドには不都合● フロントエンドにとって不都合○ 表示したいリソースを取得するため、何度もAPIリクエストを行う○ 表示しないデータまで取得してしまう● 実装が複雑化・パフォーマンスに影響17
実装上の都合● これまでのAPI開発○ フロントエンド - バックエンドの都合を同時に満たすことが難しい○ 片方が不都合な実装になりがち18
GraphQLが実装上の都合を解消する● 実装上の都合を解消するGraphQLの特徴○ フロントエンドがほしいデータを返せる○ 1回のリクエストで返せる● フロントエンドは都合を満たせ、バックエンドは不都合な実装をせずに済む19
20タグ機能開発でのスキーマ設計の例
タグ機能について21
タグのタイトルについての仕様22#Engineer #Ｅｎｇｉｎｅｅｒ作品A 作品B同じタグと識別されたいのでテキストを正規化して保持=システム内
23作品に紐づく形でタグを表示する際はユーザーが元々入力したものを表示タグのタイトルについての仕様画面表示上#Engineer #Ｅｎｇｉｎｅｅｒ作品A 作品B
画面からスキーマを検討24#タグ1作品#タグ2 #タグ3作品に紐づけられたタグを一覧できる
25#タグ作品A作品B作品Cタグが付いた作品を一覧できる画面からスキーマを検討
GraphQLスキーマの例26タグや作品をスキーマで表すとこう
27作品に紐づくタグ一覧 タグを付けた作品一覧クエリを書いてみるとこうGraphQLスキーマの例
タグの仕様を思い出す28このtitleのフィールドにユーザーが元々入力したタイトルが入る作品に紐づく形でタグを表示する際はユーザーが元々入力したものを表示
29作品に紐づく形でタグを表示する際はユーザーが元々入力したものを表示● フロントエンドは返ってきたデータを表示するだけ● バックエンドは返すデータを作品によって出し分ける必要があり、やや煩雑タグの仕様を思い出す
30作品に紐づく形でタグを表示する際はユーザーが元々入力したものを表示● バックエンド側が仕様の都合を背負う形に● できればフロントエンド-バックエンドの両方で無理の無い形で実装したいタグの仕様を思い出す
WorkTag を登場31作品に紐づくタグを表す WorkTag を登場● DBの中間テーブルのようなType● WorkTag にユーザーが元々入力したタイトルを持たせる● Work は Tagの代わりにWorkTag の配列を返す
WorkTag を登場32WorkTag 登場時のクエリ 以前のクエリ ● フロントエンドのクエリは以前とほぼ変わらない● バックエンドは中間テーブルのデータを出すだけで済むフィールドの出し分けが不要自然な実装に
両方無理のない実装が可能に● このようにGraphQLのスキーマ設計によって、フロントエンド - バックエンドで無理のない実装が可能になった● スキーマ設計時の考慮が効いた○ フロントエンドがほしいデータだけでなく○ バックエンドの実装上の都合も考慮した33
GraphQLのお陰で無理ない実装が可能● フロントエンド - バックエンドの実装の詳細から一歩引いた立場で設計することになる○ 詳細をそのままスキーマにしない○ 片方の都合によらない■ フロントエンドがほしいデータを返せる■ バックエンドが提供するリソースを表現できる34
35スキーマ設計を上手く回せている理由
回せている理由1. 開発者がフロントエンド-バックエンド両方担当2. 以前からワイヤーフレームを元に開発を開始してきた36
フロントエンド-バックエンド両方担当(1/2)● 全員がフロントエンド-バックエンド両方を担当○ 画面でほしいリソースを理解○ バックエンドの実装や都合にも通じている● スキーマを設計する際も、自然と両方の都合を考慮できている37
フロントエンド-バックエンド両方担当(2/2)38● マンガ投稿チームでは全員でスキーマ設計を行う○ スキルやドメイン知識を補完し合える● よりよいスキーマ設計に繋がる
ワイヤーフレームを元に開発開始 (1/2)● マンガ投稿チームでは、ワイヤーフレームを元に機能開発を開始するのが主流○ JSON API / テンプレートエンジンでHTMLを返す● GraphQLでも自然とワイヤーフレームを元にスキーマ設計が出来た○ ワイヤーフレーム=>リソース検討=>スキーマ設計39
● ユーザーが見るものから検討を始める○ GraphQLに限った話ではない○ JSON API / テンプレートエンジンのときもそうだった○ GraphQLよりも良い技術が出てきても適応できるだろう40ワイヤーフレームを元に開発開始 (2/2)
41まとめ
まとめ● GraphQLのスキーマ設計によって、フロントエンド-バックエンドの両方にとっていいバランスで実装が可能● マンガ投稿チームでは上手くスキーマ設計が出来ている○ 開発者がフロントエンド-バックエンド両方の開発を担当○ ワイヤーフレームを元に開発を開始42
GraphQL API を採用してわかったこと● APIの実装で困ったことはほぼ無く、それ以外の課題にフォーカスできている● フロントエンドだけでなく、バックエンドの開発にとってもメリットがある43
benevolent0505
nabedge
vividtone
globis_gdp
tacck
trycycle
fujiwara3
kojira
okada_fuutass
sprasiainc
oracle4engineer
yusuke0519
miyayou
mraible
addyosmani
rmw
cassininazir
vanstee
gr2m
chrislema
swwweet
frogandcode
eileencodes
sachag
morganepeng