自從微解封之後，現在「微XX」已經成為流行語，原來 Web 後端流行的「微服務」架構已經超前部署好幾年了(誤!)。相對於微服務熟為人知，「微框架」這個詞就沒這麼多人聽過了。微框架與微服務的「微」字，表面上看起來都是代表包含比較少的功能，但再深入探討其意義，微服務著重於拆分系統功能及權責，其結果就是一個功能較少的服務。微框架則是核心功能僅包含處理 HTTP 請求與回應，如果需要其它功能才加進來，所以微框架的特性剛好適合開發微服務，擁有輕量及簡單快速開發的優點。

在 Java 的世界中，最不缺的就是框架，其中 Spring 框架生態系最為完整，號稱「全家桶」，什麼功能都已經整合進來有解決方案，所以是最多人選擇的框架。不過既然 Spring 被稱作「全家桶」，自然就不會有人把它分類為微框架，但這不代表 Spring 不能用來開發微服務，因為「微」這個字是有程度差別，是互相比較而來的。雖然每個人的評斷標準不盡相同，但我們一般可以根據「核心功能大小」、「啟動速度」及「記憶體使用量」來比較。

由於我是因為想學 Kotlin 而想做一個 side project，在挑選 Web 框架時就不會受限於工作上的現實考量，想選擇與過往開發技術差異較大的框架，跳脫過去的思維與習慣，所以我最後選擇 JetBrains 開發的 Ktor 框架，原因是 Ktor 擁有這些特點:「微框架」、「100% 純 Kotlin」、「DSL 風格」、「Not Based on Annotations」。以微框架而言，Ktor 真的是一個非常「微」的框架，這是因為 Ktor 強調以 unopinionated 的原則進行設計，沒有內建 DI 及 ORM …等常見功能，比起我曾經使用過的 Spring Boot 及 Play 更加地輕量。架構上，Ktor 允許開發者實作 Plugin 進行擴展，透過把 intercepting function 加到 request pipeline 的方式，增加功能或改變框架行為。這種直接傳入 lambda 的寫法與主流 Spring 框架要求開發者實作特定介面或繼承特定類別，再透過 DI 注入的方式有所不同。

總結以上，我的 side project 目標就是根據我過去多年的後端開發經驗，基於 Ktor 設計實作自己理想中的 Web 框架，開發一個後端服務，實作範圍包含以下項目

• 基於 Ktor 實作支援模組化開發的 Web 框架
• 實作 Ktor Plugin 整合第三方框架及函式庫，包括 DI, ORM, Redis Client...等
• 實作 Ktor 缺少的套件來強化 Ktor，包括 i18n, OpenAPI Generator...等
• 實作「User Login Authentication & Authorization」、「Multi-Channel Notifications」…等功能

截至目前為止，codebase 累計已有 241 個 kt 檔，不含空白行超過 13000 行。專案程式碼在 GitHub => multi-projects-architecture-with-Ktor

接下來的 30 天，我會把文章重點放在說明我的設計概念與實作技巧，不重要的實作細節將會被省略，所以比較適合已經有開發經驗的後端工程師閱讀，如果您有任何建議或指正，歡迎您留言互相交流。