なぜHono×GraphQLを選んだのか？

【技術選定を突き詰める】Online Conferenc​​e 2025
https://findy.connpass.com/event/349580/

Transcript

1. 株式会社Schoo / 基盤開発ユニット / バックエンドエンジニア(PL) 福嶋 淳一 なぜHono×GraphQLを選ん だのか？ レガシーシステムの再構築に挑んだ技術選定の裏側
2. 今日伝えたいメッセージ
3. 今日伝えたいメッセージ 弊社では2024年12月から、レガシーシステムのリプレイスに着手 し、「次世代プラットフォームの構築 」に取り組んでいます。 このプロジェクトでは、これまで社内に知見やノウハウがなかった 技術をあえて採用しました。その結果、技術面・組織面の両方で失 敗を経験しました。 しかし、だからこそ得られた大きな学びがあります。 それは—— 「受け入れられるリスクと受け入れられないリスクを明確に言語 化し、あとは迷わず進むこと 」。 リスクの地図を書け 後はやるだけ
4. CONTENTS 01. プロジェクトの概要 02. BFF・Hono × GraphQLの技術選定の理由 03. 成功事例・失敗事例 04. 結論 Agenda
5. プロジェクトの概要
6. プロジェクトの概要〜なぜリプレイスするのか〜 システム老朽化 メンテナンスが困難であること サイト応答性の悪化 →「次世代プラットフォームの構築」を目指すと いう目標のもとリプレイスを行うことを決断。 →一度に全ページをリリースするのではなく、 ページ単位でリプレイスする。 ×
7. BACKEND BFF プロジェクトの概要〜システム構成〜 FRONTEND gRPC / Modular Monolith 高速・軽量なWEBフレーム ワーク 欲しいデータを、1回で、柔軟に 取得できる マイクロサービスの前段階
8. BFF プロジェクトの概要〜システム連携〜 FRONTEND query { articles { title summary author { name } } } 画面に必要な情報だけ 、無駄 なくリクエスト 画面特化しすぎると、処理の重 複しかねない。サービス単位ご とにAPIを整理して提供
9. BACKEND BFF プロジェクトの概要〜システム連携〜 gRPC / Modular Monolith ArticleService.GetArticles ArticleService.GetAuthors ドメインごとに分かれた APIか らデータを集めて、フロントに 必要な情報だけを効率よく届 ける橋渡し役 ・モジュールごとに明確な境界 があり依存は最小限 ・APIを画面ではなくドメイン起 点で作る
10. BFF・Hono × GraphQLの 技術選定の理由
11. BFFの導入理由 BFF 　バックエンドは、ドメインごとのシンプルなAPIだけ を提供している。 なので、コンテキストがまたがる場合があります。そこ で、BFFがそのつなぎ役を担い、フロントエンドが扱い やすい形に整えたいため。 　 　過去に、フロントエンドに処理の負担が多すぎる問 題があった。 その経験から、たとえば以下のような処理は、今後は BFFで担当するようにしたいと考えた： ① gRPCの取り扱いなど、複雑な通信処理 ② サーバーとやり取りするためのデータ形式（DTO）の 整形 ③ 認証や認可のロジック
12. WEBフレームワークでの比較〜軽量代表 vs 多機能代表〜 ▪Hono (軽量でシンプルなフレームワークの代表) • メリット ◦ とても軽くて動作が速い ◦ シンプルでわかりやすく、学ぶのが簡単 • デメリット ◦ 利用者（コミュニティ）がまだ少なく、情報やドキュメントが少ない ◦ GraphQLは標準で対応しておらず、別のライブラリを使う必要がある(特に、Apollo serverに対応してい ないのが難点) ▪Nest.js (機能が一通り揃った、多機能フレームワーク) • メリット ◦ 依存注入（DI）や責任分担のルールがフレームワークで整っており、設計がブレにくい • デメリット ◦ 最初に覚えることが多く、慣れるまでが大変 ◦ @Controller('users')のような独自の書き方（デコレーター）が直感的ではなく、NestJSに強く依存する コードになりやすい
13. Hono×GraphQLの導入理由 BFF ▪Hono 　　Honoはとても軽量でシンプルなフレームワーク。そ のため、JavaScriptのように変化の激しい技術でも、将 来不要になったときに捨てたり他の技術に切り替えや すいという利点がある 　　直感的でわかりやすく、学びやすい 　　非常に高速であること ▪GraphQL 　　フロントエンドが扱いやすいように、必要なデータを 1回のリクエストで柔軟にまとめて取得できるようにする
14. 成功事例・失敗事例
15. 成功事例 「技術の比較 ⇨ PoCの実施 ⇨ 社内勉強会の実施 ⇨ 1個目の機能作成時はモ ブワークを実施する 」という流れによりチーム全体で納得のいく技術選定を行え た。 良かったこと① 少しずつ知見を共有していくことで、「 知らない技術への不安 」 をチーム全体で和らげることができた。 良かったこと② 理想的な設計についてチーム全体で議論できたことで、全員 が納得できる構成に仕上げることができた。
16. 失敗事例 知見がないからこそ、デメリットに目が行きがちで、意思決定に少し時間がか かってしまった。(※慎重になって、良かったことももちろんある) 要因① 「技術選定に 100%の正解はない」と頭では分かっていても、実際に行 動に移すのは難しかった。 要因② 「どんな条件が整えば GOサインを出せるのか」が曖昧だった。 <振り返り> 「受け入れられるリスクと受け入れられないリスクを明確に言語化し、あとは迷 わず進むこと (=最後のひと押し！ )」ができなかった。目的が明確で、後戻りで きる状態を作って、力強く進むことが必要だった。 このことに途中で気づき、Honoの使用で捨てやすい状態にし、最悪の場合API Gatewayでルーティングして切り替えられば良いと判断し前に進むことを決断。
17. 結論
18. 開発道半ば。 改善することも多々あり、、
19. リスクの地図をかけ 後はやるだけ
20. そうしないと、前へ進むことはでき ない。
21. ご清聴ありがとうございまし た🙏