Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQLを使い続けて気づいたこと ~Hatena Engineer Seminar #21~
Search
Mikio Fujita
September 08, 2022
Technology
3
2.4k
GraphQLを使い続けて気づいたこと ~Hatena Engineer Seminar #21~
Hatena Engineer Seminar #21 GraphQL 活用編 での発表資料です。
https://hatena.connpass.com/event/258042/
Mikio Fujita
September 08, 2022
Tweet
Share
More Decks by Mikio Fujita
See All by Mikio Fujita
社内にアクセシビリティ改善を広める際に意識したこと
benevolent0505
0
750
エンジニアから見た出版社との共同開発の暮らし / Hatena Engineer Seminar #13
benevolent0505
0
2.2k
マンガチームとDevOps / Hatena Engineer Seminar #11
benevolent0505
0
960
授業でWebアプリを作っている?話
benevolent0505
0
900
日曜日といったら
benevolent0505
1
130
朝起きる
benevolent0505
1
83
休講
benevolent0505
0
1.2k
◯◯駆動開発
benevolent0505
0
160
WebRTCで絵チャットを作った話し
benevolent0505
0
770
Other Decks in Technology
See All in Technology
運用イベント対応への生成AIの活用 with Failure Analysis Assistant
suzukyz
0
140
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
190
バクラクにおける可観測性向上の取り組み
yuu26
3
430
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
190
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
2
110
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
170
AWS reInvent 2024 関西組 事前勉強会
shinyayamada
0
100
[AWS JAPAN 生成AIハッカソン] Dialog の紹介
yoshimi0227
0
150
事業者間調整の行間を読む 調整の具体事例
sugiim
0
1.7k
Commitment vs Harrisonism - Keynote for Scrum Niseko 2024
miholovesq
6
1.2k
チームを主語にしてみる / Making "Team" the Subject
ar_tama
4
320
Shift-from-React-to-Vue
calm1205
3
1.4k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
43
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Designing Experiences People Love
moore
138
23k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
The Cult of Friendly URLs
andyhume
78
6k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Transcript
GraphQLを 使い続けて気づいたこと 〜マンガノでの活用事例から〜 id:miki_bene Hatena Engineer Seminar #21 2022/09/07 1
自己紹介 • id:miki_bene • マンガ投稿チーム • Webアプリケーションエンジニア ◦ マンガノ /
ジャンプルーキー! / あしたのヤングジャンプ 2
今日の発表 • マンガ投稿チームで開発している マンガノというサービスの話 • 開発の当初からGraphQLを使っている ◦ 約2年ほどになる • GraphQLについて
開発を続けて気づいた点を紹介 3
• マンガノについて • GraphQLについて • GraphQLの開発を続けて気づいたこと • まとめ 4 今日の発表
5 マンガノについて
マンガノについて 6 • はてなと株式会社集英社の少年 ジャンプ+編集部が協業し提供す るマンガ投稿サービス • 2021/04よりサービス開始 • 作品の販売機能
/ 様々なWEBマ ンガ公開プラットフォームのURL を整理・公開できるポートフォリ オ機能など
7 GraphQLについて
GraphQL について • API向けのクエリ言語 • サーバーで取得可能なリソースをスキーマ定義 • クライアントはほしいデータのクエリを書き取得 8
GraphQL について 9 スキーマ クエリ 取得できるデータ
GraphQL の特徴 • 公式サイトによると ◦ クライアントがほしいデータだけを返せる ◦ 1回のリクエストで様々なデータを返せる ◦ 強力な開発者ツール
◦ etc… 10
11 GraphQLの開発を続けて 気づいたこと
開発を続けて気づいたこと 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 #Engineer 作品A 作品B 同じタグと識別されたいので テキストを正規化して保持 = システム内
23 作品に紐づく形でタグを表示する際は ユーザーが元々入力したものを表示 タグのタイトルについての仕様 画面表示上 #Engineer #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 を登場 32 WorkTag 登場時のクエリ 以前のクエリ • フロントエンドのクエリは以 前とほぼ変わらない •
バックエンドは中間テーブル のデータを出すだけで済む フィールドの出し分けが不要 自然な実装に
両方無理のない実装が可能に • このように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