Boring Technology

在軟體開發推陳出新的時代，我想可以一起回顧這篇經典文章——Choose Boring Technology，選擇無聊的技術。

在開發上，我們常常會抱怨語言選型落伍，PHP 屎山程式碼應該要全部重構成 Rust 或 Golang 或任何你想得到的程式語言。資料庫用 Postgres 或 MySQL 太落伍了，要用 Mongo、DynamoDB、Cassendra、Neo4j 才可以應付大流量。

通常有「引入某個新技術」可以解決既有問題的想法，大多代表開發還沒有想得足夠清楚而已。不過要體悟這件事，通常需要時間積累。從碰到新技術眼睛會發光的少年到變成油光滿面的中年大叔。

跟其他不理解的開發者講這件事，他們只會覺得那是不想學習新東西的老人才會有的想法，但正因為見識過起起伏伏，進入到第三境界的看山是山、看水是水，才知道無聊的技術往往是最棒的技術。

我們天生不喜歡無聊，因為無聊代表停滯、缺乏新鮮感。但在軟體世界裡，「無聊」代表穩定、成熟與被實戰驗證。技術的刺激感常常是以維運的代價換來的。

在 Vercel 的不斷推廣下，很多 SaaS 服務會使用 Next.js 進行全端開發，雖然搭配 LLM 與 Vercel 自家平台優勢，可以很快推出產品並無痛部署，但也讓我意識到它所帶來的複雜度。

像是寫 React 元件需要理解前後端差異的複雜度；Server Actions / Server Component / Client Component 的選擇，這些都是為了達到他們聲稱更好的 UX 而做的取捨。

倒也不是說 Vercel 不好，它與 Next.js 的整合相當好，支援 SSG / SSR，也支援純靜態生成。SSR 的版本會幫你把 Next.js 需要伺服器的函數自動轉成 Edge Functions、自動部署、回滾（Rollback）、堪用的 Log 與告警系統，這些都是相當有幫助的功能。

但也不是完全無缺點，像是在需求逐漸複雜之後，光是 Library 的選型就相當惱人：

• 權限管理
• 表單驗證
• JWT 等機制實作
• 資料庫的 migration 管理
• Websocket 或 SSE
• Background Job / Scheduled Job / Cron Job 或任何非同步處理機制

或是認知到 Edge Functions 與本地開發的差異，導致有些程式碼的行為會完全不同。

也可以理解為選擇的自由，但對剛起步的公司或開發者來說，花時間在這些地方踩坑，雖說是個有趣的體驗，然而這對需要推出產品的公司來說並不是 CP 值高的選擇。很多框架在很早期的階段就已經解決這些事情了，像是以上提到的機制 Django / Laravel / Ruby On Rails 都具備。

以我現在的工作內容來說，由於涉及比較多圖片處理的關係，需要針對 CPU-bound 做優化最後選擇 AWS SQS 解決，但剩下的部分都是靠 Django 內建的功能實作的。雖然 Django 對非同步的支援沒那麼好，但他的確省下了很多時間。部署也是一個需要高度關注的事，因為很容易把它複雜化。

接下來說說如果要我選擇的話，我會怎麼選。我認為一個無聊的框架應該具備下列幾個要件：

• 具有內建且完整的 Database Adapter 與 Migration 機制：這點很容易被忽略但有 migration 這點至關重要
  • 這點有時是雙面刃，例如某些 DB 沒有 uuid 的實作，導致需要在應用端生成 uuid 寫入資料庫
• 呈上，便利、彈性的 ORM：像 Django 與 Ruby On Rails 的模型寫起來就相當舒服。同時也要具備必要時能下 Raw SQL Query 的能力。我知道很多開發者討厭 ORM 帶來的封裝與不夠彈性的介面，但粗暴地忽略它帶來的便利性與維護性是不現實的。
• 登入、權限控管機制：至少要能夠在 API 層級做權限控管，例如（以 Django 舉例）

# 在 request 過來時會根據設定的 permission 控管
class MyProfileAPIView(APIView):
    permission_classes = [IsAuthenticated, xxxGroupPermission]

• 有整合 Background Job 的機制：像是 Django 時常搭配的 Celery 或是 Ruby On Rails 的 ActiveJob
• 是否支援 Cache：最好是有 adapter，可以自由切換 in-memory 或是 Redis
• 是否支援 Websocket 的抽象：例如 Django 的 channel；Ruby On Rails 的 Action Cable
  • 有時候 Websocket 的需求就是會突然冒出來
• 是否容易在本地端跑起來
• 有內建的後台生成機制：只要定義好 Model 與 UI 選項即可生成後台頁面

class File(MyModel):
    device_id = models.CharField(
        max_length=255,
        verbose_name="設備ID",
        null=True,
        blank=True
    )
    
admin.site.register(File, FileAdmin)

這樣寫，Django 會自動生成對應的頁面，讓你能夠修改資料庫裡面的值，也能進行簡單的客製化。老實說這個功能是我後來發現極為重要的。

如果給開發者自己做後台，光是技術選型就要一陣子，如果又想要做到前後端分離，代表又要再花時間串接 UI、API、資料庫。相比 Django 儘管頁面陽春，但能直接透過宣告 Model 節省 90% 的工作且又能保證完全正確，是極為方便的功能。

每個框架或多或少有其局限性或缺點，然而我認為一個「好的無聊框架」應該具備以下七個特徵：

1. ✅ 原生支援非同步或輕量並行（green thread / coroutine）
2. 🧱 穩定的資料庫整合與 Migration 機制**
3. 🧩 好用但不強制的 ORM，能自由使用 Raw SQL
4. 🔐 內建登入與權限控管機制
5. ⚙️ 整合 Background Job 或排程機制（Celery / ActiveJob）
6. 🪄 自動生成後台 UI（例如 Django Admin）
7. 💾 完善的 Cache 與 Websocket 支援

華麗的技術能吸引注意，但真正能撐過風雨的，永遠是那些無聊、可靠的選擇。

後記

DHH 在 Rails World 的 Keynote 曾經提到現在網頁開發的現況簡直過於複雜。以前只要把東西拖過去 SFTP 就直接上線了，現在跑個 CI/CD 就要 15 分鐘。雖然不完全認同 DHH 的看法，但我想只要是網頁開發者，多多少少都有過「過度複雜」的念頭吧。