Hono 框架 - Clean Architecture in TypeScript

這一系列我們會使用 Hono 這一個近幾年才出現的框架，跟 Node 生態系常使用的 Express 框架不同，Hono 最初是以 Cloudflare Worker 環境運行設計，後來逐漸發展成適合 Serverless 環境的框架。

部署彈性

之所以選擇 Hono 的主要原因是非常容易部署，JavaScript 作為大多數 Serverless 平台的主要語言，再加上 Hono 可以非常簡單的和 TypeScript 搭配，這讓部署到各種不同的環境都非常簡單。

很多時候，我們開發的專案規模很小，或者沒有大量、持續的流量需求，選擇使用獨立、持續運行的伺服器大多成本會偏高，然而 Serverless 類型的部署就可以依照用量付費，在開發初期可以節省大量成本。

然而，Serverless 在許多平台的單位收費是比虛擬機器（Virtual Machine）還貴上不少，因此能夠彈性的轉換成使用 Node、Bun 環境的 HTTP 伺服器透過虛擬機器、容器技術部署，也能更彈性的應對成長。

Hono 框架讓我們很容易就可以實現這樣的轉換，因此作為一個現代框架是相當不錯的選項。

RPC

Hono 內建了一個非常輕量的 RPC 機制，透過 TypeScript 的型別特性可以很輕鬆的開發 API Client 這點也是在這一系列中選擇使用 Hono 的理由之一。

以往我們習慣使用 RESTful API 的方式設計，然而 RESTful API 大多時候比較適合用來表示某個資源（Resource）的操作（CRUD，讀取、寫入、修改、刪除）但在實際的商業行為上，大多不會剛好滿足這樣的情境。

RPC 的定義方式是以某一個「流程」為基礎驅動的，像是「建立訂單」這樣的概念，很多時候反而可以更好的表現特定行為，有興趣可以閱讀 Google Cloud 的 gRPC vs REST: Understanding gRPC, OpenAPI and REST and when to use them in API design 這篇文章來了解差異，以及 Google 在 gRPC 背後思考的一些想法。

gRPC 使用 Protobuf 作為基礎，同時也讓 Protobuf 的 .proto 變成一種 IDL（介面定義語言）來標準化 API 介面的定義方式。

Hydrate（合成）

近年前端領域很常將前端、後端一起實作，甚至混合在一起處理，這類技術被稱作是 Hydrate 的方式，在 Hono 也一定程度能夠支援，即使目前尚未有完善的基礎，但也是值得期待的特性之一。

作為 Hydrate 的前提，Hono 支援使用 JSX 在後端直接渲染網頁，甚至製作簡單的非同步載入機制。既然能夠在後端使用 JSX 渲染網頁，那麼必定能夠用於前端相關的實作。

雖然不多，但是 Hono 也提供了一小部分 React 相容的 API 讓我們作為 React 的替代，相比 React 壓縮後仍有 47KB 的大小，使用 Hono 只有 2KB 的情境，我們可以製作一個非常輕量且快速的前端介面。

這些特性讓我們在這系列除了依賴 Vercel 的 AI SDK 來取用語言模型之外，幾乎可以使用 Hono 完成所有必備功能的開發。