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
なぜHono×GraphQLを選んだのか?
Search
福嶋淳一
May 13, 2025
Programming
1
2.2k
なぜHono×GraphQLを選んだのか?
【技術選定を突き詰める】Online Conference 2025
https://findy.connpass.com/event/349580/
福嶋淳一
May 13, 2025
Tweet
Share
More Decks by 福嶋淳一
See All by 福嶋淳一
システムリプレイスのタイミングでPlaywrightを入れた話
junichi_fukushima
0
10
Other Decks in Programming
See All in Programming
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
600
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
220
サイトを作ったらNFCタグキーホルダーを爆速で作れ!
yuukis
0
620
開発チーム・開発組織の設計改善スキルの向上
masuda220
PRO
15
8.7k
物語を動かす行動"量" #エンジニアニメ
konifar
14
5.5k
Langfuseと歩む生成AI活用推進
licux
3
310
AIレビュアーをスケールさせるには / Scaling AI Reviewers
technuma
2
230
コンテキストエンジニアリング Cursor編
kinopeee
1
720
ソフトウェアテスト徹底指南書の紹介
goyoki
1
110
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
180
Namespace and Its Future
tagomoris
6
580
【第4回】関東Kaggler会「Kaggleは執筆に役立つ」
mipypf
0
900
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
525
40k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
480
The World Runs on Bad Software
bkeepers
PRO
70
11k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Site-Speed That Sticks
csswizardry
10
790
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Optimizing for Happiness
mojombo
379
70k
Writing Fast Ruby
sferik
628
62k
Transcript
株式会社Schoo / 基盤開発ユニット / バックエンドエンジニア(PL) 福嶋 淳一 なぜHono×GraphQLを選ん だのか? レガシーシステムの再構築に挑んだ技術選定の裏側
今日伝えたいメッセージ
今日伝えたいメッセージ 弊社では2024年12月から、レガシーシステムのリプレイスに着手 し、「次世代プラットフォームの構築 」に取り組んでいます。 このプロジェクトでは、これまで社内に知見やノウハウがなかった 技術をあえて採用しました。その結果、技術面・組織面の両方で失 敗を経験しました。 しかし、だからこそ得られた大きな学びがあります。 それは—— 「受け入れられるリスクと受け入れられないリスクを明確に言語
化し、あとは迷わず進むこと 」。 リスクの地図を書け 後はやるだけ
CONTENTS 01. プロジェクトの概要 02. BFF・Hono × GraphQLの技術選定の理由 03. 成功事例・失敗事例 04.
結論 Agenda
プロジェクトの概要
プロジェクトの概要〜なぜリプレイスするのか〜 システム老朽化 メンテナンスが困難であること サイト応答性の悪化 →「次世代プラットフォームの構築」を目指すと いう目標のもとリプレイスを行うことを決断。 →一度に全ページをリリースするのではなく、 ページ単位でリプレイスする。 ×
BACKEND BFF プロジェクトの概要〜システム構成〜 FRONTEND gRPC / Modular Monolith 高速・軽量なWEBフレーム ワーク
欲しいデータを、1回で、柔軟に 取得できる マイクロサービスの前段階
BFF プロジェクトの概要〜システム連携〜 FRONTEND query { articles { title summary author
{ name } } } 画面に必要な情報だけ 、無駄 なくリクエスト 画面特化しすぎると、処理の重 複しかねない。サービス単位ご とにAPIを整理して提供
BACKEND BFF プロジェクトの概要〜システム連携〜 gRPC / Modular Monolith ArticleService.GetArticles ArticleService.GetAuthors ドメインごとに分かれた
APIか らデータを集めて、フロントに 必要な情報だけを効率よく届 ける橋渡し役 ・モジュールごとに明確な境界 があり依存は最小限 ・APIを画面ではなくドメイン起 点で作る
BFF・Hono × GraphQLの 技術選定の理由
BFFの導入理由 BFF バックエンドは、ドメインごとのシンプルなAPIだけ を提供している。 なので、コンテキストがまたがる場合があります。そこ で、BFFがそのつなぎ役を担い、フロントエンドが扱い やすい形に整えたいため。 過去に、フロントエンドに処理の負担が多すぎる問 題があった。
その経験から、たとえば以下のような処理は、今後は BFFで担当するようにしたいと考えた: ① gRPCの取り扱いなど、複雑な通信処理 ② サーバーとやり取りするためのデータ形式(DTO)の 整形 ③ 認証や認可のロジック
WEBフレームワークでの比較〜軽量代表 vs 多機能代表〜 ▪Hono (軽量でシンプルなフレームワークの代表) • メリット ◦ とても軽くて動作が速い ◦
シンプルでわかりやすく、学ぶのが簡単 • デメリット ◦ 利用者(コミュニティ)がまだ少なく、情報やドキュメントが少ない ◦ GraphQLは標準で対応しておらず、別のライブラリを使う必要がある(特に、Apollo serverに対応してい ないのが難点) ▪Nest.js (機能が一通り揃った、多機能フレームワーク) • メリット ◦ 依存注入(DI)や責任分担のルールがフレームワークで整っており、設計がブレにくい • デメリット ◦ 最初に覚えることが多く、慣れるまでが大変 ◦ @Controller('users')のような独自の書き方(デコレーター)が直感的ではなく、NestJSに強く依存する コードになりやすい
Hono×GraphQLの導入理由 BFF ▪Hono Honoはとても軽量でシンプルなフレームワーク。そ のため、JavaScriptのように変化の激しい技術でも、将 来不要になったときに捨てたり他の技術に切り替えや すいという利点がある 直感的でわかりやすく、学びやすい 非常に高速であること ▪GraphQL
フロントエンドが扱いやすいように、必要なデータを 1回のリクエストで柔軟にまとめて取得できるようにする
成功事例・失敗事例
成功事例 「技術の比較 ⇨ PoCの実施 ⇨ 社内勉強会の実施 ⇨ 1個目の機能作成時はモ ブワークを実施する 」という流れによりチーム全体で納得のいく技術選定を行え
た。 良かったこと① 少しずつ知見を共有していくことで、「 知らない技術への不安 」 をチーム全体で和らげることができた。 良かったこと② 理想的な設計についてチーム全体で議論できたことで、全員 が納得できる構成に仕上げることができた。
失敗事例 知見がないからこそ、デメリットに目が行きがちで、意思決定に少し時間がか かってしまった。(※慎重になって、良かったことももちろんある) 要因① 「技術選定に 100%の正解はない」と頭では分かっていても、実際に行 動に移すのは難しかった。 要因② 「どんな条件が整えば GOサインを出せるのか」が曖昧だった。
<振り返り> 「受け入れられるリスクと受け入れられないリスクを明確に言語化し、あとは迷 わず進むこと (=最後のひと押し! )」ができなかった。目的が明確で、後戻りで きる状態を作って、力強く進むことが必要だった。 このことに途中で気づき、Honoの使用で捨てやすい状態にし、最悪の場合API Gatewayでルーティングして切り替えられば良いと判断し前に進むことを決断。
結論
開発道半ば。 改善することも多々あり、、
リスクの地図をかけ 後はやるだけ
そうしないと、前へ進むことはでき ない。
ご清聴ありがとうございまし た🙏