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で実現するバックエンド開発のイマ
Search
sugar-cat
October 21, 2024
17
2.2k
Honoで実現するバックエンド開発のイマ
sugar-cat
October 21, 2024
Tweet
Share
More Decks by sugar-cat
See All by sugar-cat
GoとWASI~超入門~
sugarcat7
2
200
最近個人開発が熱い ~多言語対応編~
sugarcat7
1
210
ボイラープレート自動生成ツールを使わなくなった話.pdf
sugarcat7
4
480
Using_Hono_in__B2B_SaaS_Application.pdf
sugarcat7
6
330
Introduction to Database Connection Management Patterns in TypeScript.pdf
sugarcat7
1
350
Azure Container AppsのSecret管理とIaC
sugarcat7
1
180
最近個人開発が熱い
sugarcat7
15
14k
新規サービスの バックエンド開発でBun×Honoを使い始めて 2ヶ月経った話
sugarcat7
2
1.3k
gRPCとフロントエンド_Connectを添えて
sugarcat7
2
1.7k
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
The Language of Interfaces
destraynor
154
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
Automating Front-end Workflow
addyosmani
1365
200k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Docker and Python
trallard
40
3.1k
Git: the NoSQL Database
bkeepers
PRO
425
64k
How to Think Like a Performance Engineer
csswizardry
19
1.1k
How GitHub (no longer) Works
holman
311
140k
4 Signs Your Business is Dying
shpigford
180
21k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Transcript
Honoで実現する バックエンド開発のイマ 2024/10/22 Express/NextJS/Hono運用者に聞くバックエンドTSのイマ @sugar235711
2 sugar cat(@sugar235711) 社会人3年生 SREもどき パフォーマンスとセキュリティが好き [登壇] Hono Conference 2024
・Using Hono in B2B SaaS [ブログ] Honoを使い倒したい2024 HonoとCasbinで認可制御を実装する 登壇者情報 @sugar235711 @sugar-cat7
3 Agenda 1. バックエンドTS特有の難しさ 2. HonoとTypeScriptバックエンド開発 3. まとめ
4 この発表の対象者 ・紆余曲折を経てバックエンドTSをやっていき!な方 ・Honoが気になる方 ・Hono×TSの運用周りで気をつけたいポイントを知りたい方 はじめに
5 他言語出身者がバックエンドTSを始める上での大きな参入障壁 広大なエコシステム 1. バックエンドTS特有の難しさ
6 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc 広大なエコシステム 1. バックエンドTS特有の難しさ
7 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンドTS特有の難しさ
8 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンドTS特有の難しさ
9 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ 何を基準に 選べば良い?🤔
一般的なAPIを作る前提で考えてみる
10 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ Cloud Providerは?
・AWS/Google Cloud…etc 作りたいサービスにあっ たインフラを選定
11 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc 使用予定のサービスでの ランタイム対応状況 ・distroless等の軽量なイメージで動くの か ・Node以外のランタイムは対応しているの か、バージョンはどうか
12 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc ・SDK経由?Integrationは必要? 公式SDKやサービスを シームレスに使えるのが ベスト
13 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc ・SDK経由?Integrationは必要? 開発者体験を優先したい? ・特殊な実装WebSocketやSSE の実装を楽したい ・OpenAPIやtRPCを使ってス キーマ駆動の開発がしたい 他チームとの共同をし易く、かつ負 債になり得る実装は極力自前で実装 しない
14 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ そんなことが 実現できる?
15 1. バックエンド TS特有の難しさ
16 Web標準に基づき、軽量で、高速に、どんなJavaScriptランタイムでも動く Webフレームワーク • 特徴 ◦ 実行環境の差分を吸収できるAdapter ◦ 組み込みでWeb標準のAPIを扱い易くしたHelper ◦
Webアプリケーション開発で必要になる便利機能を詰め込んだ Middleware ◦ 型システムを生かした開発ができるRPC Modeのサポート Hono概要 1. バックエンドTS特有の難しさ
17 Web標準に基づき、軽量で、高速に、どんなJavaScriptランタイムでも動く Webフレームワーク • 特徴 ◦ 実行環境の差分を吸収できるAdapter ◦ 組み込みでWeb標準のAPIを扱い易くしたHelper ◦
Webアプリケーション開発で必要になる便利機能を詰め込んだ Middleware ◦ 型システムを生かした開発ができるRPC Modeのサポート Hono概要 1. バックエンドTS特有の難しさ
18 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc Honoなら.... ・Web標準にしたがっているので (基本)どのランタイムでも動く →Node/Deno/Bun/Workerd関係ない、 Adapterからランタイム固有のAPIも簡 単に使用できる
19 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc ・SDK経由?Integrationは必要? Honoなら.... ・Adapterで実行環境の差異を吸収 し、Mountで様々なフレームワーク と統合が可能
20 他言語出身者がバックエンドTSを始める上での大きな参入障壁 ランタイム/バンドラ/パッケージマネージャー/Linter/Formatter….etc デファクトっぽいものがたくさんある。何を選んで良いのかわからない。 広大なエコシステム 1. バックエンド TS特有の難しさ ホスティングするサービスは? ・Container
Base ・EKS/ECS… ・Serverless Function ・Lambda… Cloud Providerは? ・AWS/Google Cloud…etc ・SDK経由?Integrationは必要? 開発者体験を優先したい? ・特殊な実装WebSocketやSSE の実装を楽したい ・OpenAPIやtRPCを使ってス キーマ駆動の開発がしたい Honoなら.... ・ミドルウェアが充実(一般的な Web開発で必要なものは大体ある) ・Helperを使用してStreamや WebSocketを扱える
21 Honoの構成要素 1. バックエンドTS特有の難しさ Middeware [Built in] ・CORS ・Authentication ・Cache
[Third Party] ・Zod OpenAPI ・GraphQL Server ・OAuth Providers Adapter ・node ・bun ・deno ・workerd ・edge-light ・fastly ・env Helper ・JWT ・Streaming ・WebSocket ・html ・SSG ・Testing
22 よくありそうなWebアプリケーションの構成 Honoとバックエンドの実装パターン 2. HonoとTypeScriptバックエンド開発
23 BFFでHonoを使う Honoとバックエンドの実装パターン1: BFF 2. HonoとTypeScriptバックエンド開発
24 昨今のBFF: Next.js(Pages RouterのAPI Routes/ AppRouterのRSC)/GraphQL Server…etc Honoとバックエンドの実装パターン1: BFF 2.
HonoとTypeScriptバックエンド開発
25 Next.jsにはAPI RoutesやAppRouterのRSC等のBFF相当の機能を実装できる(略) HonoとBFFの例: Next.js×Hono 2. HonoとTypeScriptバックエンド開発
26 Next.jsにはAPI RoutesやAppRouterのRSC等のBFF相当の機能を実装できる(略) VercelのAdapterでHonoとAPI Routeを統合しBFFを開発可能 HonoとBFFの例: Next.js×Hono 2. HonoとTypeScriptバックエンド開発
27 Next.jsにはAPI RoutesやAppRouterのRSC等のBFF相当の機能を実装できる(略) VercelのAdapterでHonoとAPI Routeを統合しBFFを開発可能 HonoとBFFの例: Next.js×Hono 2. HonoとTypeScriptバックエンド開発 Pages
Router ・pages/api/[[...route]].ts
28 Next.jsにはAPI RoutesやAppRouterのRSC等のBFF相当の機能を実装できる(略) VercelのAdapterでHonoとAPI Routeを統合しBFFを開発可能 HonoとBFFの例: Next.js×Hono 2. HonoとTypeScriptバックエンド開発 Pages
Router ・pages/api/[[...route]].ts AppRouter ・app/api/[[...route]]/route.ts
29 バックエンドサーバーでHonoを使う Honoとバックエンドの実装パターン 2. HonoとTypeScriptバックエンド開発
30 1.マイクロサービス間の1つのバックエンドサービスとしてのAPI(異なる言語の サーバーから利用される) ・Zod OpenAPIベースのREST API 2.クライアント(Browser)、サーバー間でのAPI ・素のHonoだけでREST API ・Zod
OpenAPIベースのREST API ・Hono RPC Honoとバックエンドの実装パターン 2. HonoとTypeScriptバックエンド開発
31 1.マイクロサービス間の1つのバックエンドサービスとしてのAPI(異なる言語の サーバーから利用される) ・Zod OpenAPIベースのREST API 2.クライアント(Browser)、サーバー間でのAPI ・素のHonoだけでREST API ・Zod
OpenAPIベースのREST API ・Hono RPC Honoとバックエンドの実装パターン 2. HonoとTypeScriptバックエンド開発
32 Third Party Middlewareの@hono/zod-openapi+@hono/swagger-uiでZod OpenAPIベースのスキーマでRequestのValidationからSwagger UIまで自動生成 Zod OpenAPIベースのREST API 2.
HonoとTypeScriptバックエンド開発
33 Third Party Middlewareの@hono/zod-openapi+@hono/swagger-uiでZod OpenAPIベースのスキーマでRequestのValidationからSwagger UIまで自動生成 Zod OpenAPIベースのREST API 2.
HonoとTypeScriptバックエンド開発 ZodベースでRequest/Response のSchemaを定義
34 Third Party Middlewareの@hono/zod-openapi+@hono/swagger-uiでZod OpenAPIベースのスキーマでRequestのValidationからSwagger UIまで自動生成 Zod OpenAPIベースのREST API 2.
HonoとTypeScriptバックエンド開発 OpenAPIHonoのインスタンスを作 成し、routeに紐づく処理を実装
35 Third Party Middlewareの@hono/zod-openapi+@hono/swagger-uiでZod OpenAPIベースのスキーマでRequestのValidationからSwagger UIまで自動生成 Zod OpenAPIベースのREST API 2.
HonoとTypeScriptバックエンド開発 Routeの定義からjsonを作成し、 jsonを元にSwaggerUIを生成
36 いわゆるtRPC相当のことができる機能 普通のREST APIを書き、Routeの型をhono/clientに渡すことで、型補完の恩恵を 受けることができる、もちろんZod OpenAPIのREST APIとも併用可能 Hono RPC 2.
HonoとTypeScriptバックエンド開発
37 いわゆるtRPC相当のことができる機能 普通のREST APIを書き、Routeの型をhono/clientに渡すことで、型補完の恩恵を 受けることができる、もちろんZod OpenAPIのREST APIとも併用可能 Hono RPC 2.
HonoとTypeScriptバックエンド開発 hcをベースにAPIリクエストやレス ポンスを型安全に扱える。 built inの機能なので内部はfetch のラッパー。どこでも動く。
38 サービスを効率よく開発して終わり...ではない。ユーザーに使用してもらい改善の サイクルを回せるようになってからが本番 運用で気を付けること 3. 運用について
39 サービスを効率よく開発して終わり...ではない。ユーザーに使用してもらい改善の サイクルを回せるようになってからが本番 運用では何を気 を付ける?🤔 運用で気を付けること 3. 運用について
40 一般的にサービスが機能するために開発者が持続的にSLI/SLOに沿った監視を行 い、サービスの健全性を保証できている状態にすることが理想 運用で気を付けること 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層
41 一般的にサービスが機能するために開発者が持続的にSLI/SLOに沿った監視を行 い、サービスの健全性を保証できている状態にすることが理想 運用で気を付けること 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層
42 指標となるメトリクスやトレースを収集し、システムの状態を把握できるようにモ ニタリングを行う モニタリング 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層
43 指標となるメトリクスやトレースを収集し、システムの状態を把握できるようにモニタリン グを行う モニタリング 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層 何の指標を集める? ・APIごとのリクエスト数 ・CPU/Memory使用率 ・API ごとのエラー率
44 指標となるメトリクスやトレースを収集し、システムの状態を把握できるようにモニタリン グを行う モニタリング 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層 何の指標を集める? ・APIごとのリクエスト数 ・CPU/Memory使用率 ・API ごとのエラー率 使用する監視ツールは? ・DatadogやNewRelicの監視 Saas ・各クラウドプロバイダーの監視 ツール
45 指標となるメトリクスやトレースを収集し、システムの状態を把握できるようにモニタリン グを行う モニタリング 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層 何の指標を集める? ・APIごとのリクエスト数 ・CPU/Memory使用率 ・API ごとのエラー率 使用する監視ツールは? ・DatadogやNewRelicの監視 Saas ・各クラウドプロバイダーの監視 ツール アプリケーションの改修は必要? ・エラースキーマやハンドリング は適切か ・構造化ログはとっているか ・トレースやプロファイリングを しているか
46 指標となるメトリクスやトレースを収集し、システムの状態を把握できるようにモニタリン グを行う モニタリング 3. 運用について SRE サイトリライアビリティエンジニアリング 図III -1
サービスの信頼性の階層 何の指標を集める? ・APIごとのリクエスト数 ・CPU/Memory使用率 ・API ごとのエラー率 使用する監視ツールは? ・DatadogやNewRelicの監視 Saas ・各クラウドプロバイダーの監視 ツール アプリケーションの改修は必要? ・エラースキーマやハンドリング は適切か ・構造化ログはとっているか ・トレースやプロファイリングを しているか Hono×TypeScriptでどうする?
47 Honoにはエラーハンドリングの仕組みが提供されている エラースキーマとエラーハンドリング 3. 運用について
48 Honoにはエラーハンドリングの仕組みが提供されている エラースキーマとエラーハンドリング 3. 運用について トップレベルのonErrorメソッド でエラーをキャッチできる
49 Honoにはエラーハンドリングの仕組みが提供されている エラースキーマとエラーハンドリング 3. 運用について 認証時のエラーなどのHTTPステー タスコードを指定してエラーをス ローする
50 HonoではContextがリクエスト単位で生成されるオブジェクトになる。 LoggerやRequestID等リクエストごと一意に扱いたい値はContextで伝搬させ る。 構造化ロギング 3. 運用について
51 HonoではContextがリクエスト単位で生成されるオブジェクトになる。 LoggerやRequestID等リクエストごと一意に扱いたい値はContextで伝搬させ る。 構造化ロギング 3. 運用について ContextにLoggerをセット
52 HonoではContextがリクエスト単位で生成されるオブジェクトになる。 LoggerやRequestID等リクエストごと一意に扱いたい値はContextで伝搬させ る。 構造化ロギング 3. 運用について RequestId Middlewareで ContextにRequestIDをセット
53 HonoではContextがリクエスト単位で生成されるオブジェクトになる。 LoggerやRequestID等リクエストごと一意に扱いたい値はContextで伝搬させ る。 構造化ロギング 3. 運用について ContextStorage Middlewareで グローバルに扱えるようにする
(AsyncLocalStorage)
54 HonoではContextがリクエスト単位で生成されるオブジェクトになる。 LoggerやRequestID等リクエストごと一意に扱いたい値はContextで伝搬させ る。 構造化ロギング 3. 運用について Contextは型付けして、 Injection 対象を安全に扱う
55 今までは指標となるメトリクスやトレースの取得のためのInterfaceは各監視ベン ダーの実装に依存していた。 メトリクス・トレース 3. 運用について
56 今までは指標となるメトリクスやトレースの取得のためのInterfaceは各監視ベン ダーの実装に依存していた。 →昨今ではベンダーフリーな実装を行うためにOTLPベースのテレメトリデータを 取得できるOpenTelemetryが主流になっている メトリクス・トレース 3. 運用について
57 ロガー同様Context経由でTracerを伝搬させる Hono×OpenTelemetry 3. 運用について
58 ロガー同様Context経由でTracerを伝搬させる Hono×OpenTelemetry 3. 運用について Context内に保持するオブジェク トに型付け
59 ロガー同様Context経由でTracerを伝搬させる Hono×OpenTelemetry 3. 運用について Contextから型安全にオブジェク トを取り出し
60 ロガー同様Context経由でTracerを伝搬させる Hono×OpenTelemetry 3. 運用について ビジネスロジックに計装をする
61 AgentやIntegrationを活用して監視Saasと連携し、アプリケーションに計装を行 うことで、システムの内部を可視化できる 監視SaaSでモニタリングする 3. 運用について
62 Hono×TypeScriptで最高の開発者体験を得よう! まとめ あらゆる環境に対応する ・Node ・Bun ・Deno 型安全に開発する ・RPC Mode
・Zod/OpenAPI Context経由で計装する ・Binding ・ContextStorage