在軟體開發推陳出新的時代，我想可以一起回顧這篇經典文章——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 而做的取捨。

然而這也造成了在需求逐漸複雜之後，光是 Library 的選型就相當惱人：

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

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

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

建議

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

• 語言本身具有 green thread 機制或 async 機制：像是 Go 的 goroutine；Kotlin 的 coroutine； Python 的 asyncio
• 具有內建且完整的 Database Adapter 與 Migration 機制：這點很容易被忽略但有 migration 這點至關重要
  • 這點有時是雙面刃，例如某些 DB 沒有 uuid 的實作，導致需要在應用端生成 uuid 寫入資料庫
• 呈上，便利、彈性的 ORM：像 Django 與 Ruby On Rails 的模型寫起來就相當舒服。同時也要具備必要時能下 Raw SQL Query 的能力
• 登入、權限控管機制：至少要能夠在 API 層級做權限控管，例如（以 Django 舉例）

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

• 有整合 Background Job 的機制：像是 Django 時常搭配的 Celery 或是 Ruby On Rails 的 ActiveJob
• 有內建的後台生成機制：只要定義好 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、資料庫。儘管頁面陽春，但能直接透過宣告 Model 節省 90% 的工作且又能保證完全正確，是極為方便的功能。

• 是否支援 Cache：最好是有 adapter，可以自由切換 in-memory 或是 Redis
• 是否支援 Websocket 的抽象：例如 Django 的 channel；Ruby On Rails 的 Action Cable
  • 有時候 Websocket 的需求就是會突然冒出來
• 是否容易在本地端跑起來

什麼時候可以用你想要的那些高大上的技術？到那個時候自然就知道了。