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.6k
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
890
エンジニアから見た出版社との共同開発の暮らし / Hatena Engineer Seminar #13
benevolent0505
0
2.4k
マンガチームとDevOps / Hatena Engineer Seminar #11
benevolent0505
0
1k
授業でWebアプリを作っている?話
benevolent0505
0
970
日曜日といったら
benevolent0505
1
130
朝起きる
benevolent0505
1
89
休講
benevolent0505
0
1.2k
◯◯駆動開発
benevolent0505
0
190
WebRTCで絵チャットを作った話し
benevolent0505
0
830
Other Decks in Technology
See All in Technology
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
400
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
11
4.6k
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
1
460
データアナリストからアナリティクスエンジニアになった話
hiyokko_data
2
440
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
19
8.6k
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
10
3k
AWSで始める実践Dagster入門
kitagawaz
1
580
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1k
人工衛星のファームウェアをRustで書く理由
koba789
13
7.1k
ガチな登山用デバイスからこんにちは
halka
1
230
Django's GeneratedField by example - DjangoCon US 2025
pauloxnet
0
120
AIのグローバルトレンド2025 #scrummikawa / global ai trend
kyonmm
PRO
1
260
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
520
Testing 201, or: Great Expectations
jmmastey
45
7.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
GitHub's CSS Performance
jonrohan
1032
460k
Designing for humans not robots
tammielis
253
25k
Agile that works and the tools we love
rasmusluckow
330
21k
Documentation Writing (for coders)
carmenintech
74
5k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
The Invisible Side of Design
smashingmag
301
51k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
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