前后端分離幾乎已經成為 Web 應用開發的標準模式，但它也帶來了不少工程負擔。

開發者通常需要在前端和后端分別定義領域模型。隨著項目演進，這兩套模型幾乎必然會在某個時間點出現不一致。除此之外，團隊還需要處理數據序列化、跨語言類型約束，以及前后端拆分后帶來的開發、調試和協作割裂感。

于是，一個很自然的問題出現了：

為什么不能用同一種語言開發前端和后端，并盡可能共享代碼？

問題在于，前端和后端運行在完全不同的環境中，對技術棧的要求也不一樣。

在后端，開發者通常更關心低延遲、可預測的內存使用和原始計算能力。而在瀏覽器端，應用需要很好地融入 JavaScript 生態，并盡可能控制包體積。這些約束并不一致，因此很難用單一編譯目標同時滿足兩端需求。

MoonBit 嘗試提供另一種思路： 支持多種編譯目標，讓系統的不同部分運行在最適合自己的環境中。

目前，MoonBit 可以面向不同目標進行編譯：

• Native ：使用 Perceus 內存管理算法，避免 GC 停頓并降低內存開銷，適合性能敏感的后端服務。

• JavaScript ：可以直接運行在 JS 運行時上，便于與 DOM 和瀏覽器 API 交互，不需要額外的中間層。

• WebAssembly ：適合計算密集型前端邏輯，通?？梢詭砀玫男阅芎透〉陌w積。

這意味著，開發者不需要強行把所有代碼塞進同一個目標，而是可以根據不同模塊的運行環境選擇合適的編譯目標，同時保持核心邏輯共享。

當然，這也帶來了新的問題：這樣的項目應該如何組織？代碼如何跨目標共享？又如何避免整個開發流程變得混亂？

本文將通過一個簡單的 Todo 應用，看看 MoonBit 的工具鏈如何在實踐中處理這些問題。

Workspace 與 supported_targets

MoonBit 0.9.0 工具鏈最初引入了 moon.work 配置。 moon.work 表示一個 workspace，可以聲明多個需要一起管理的 MoonBit 模塊。

例如，假設 projects 文件夾中包含 module1 和 module2 兩個模塊：

projects
  +- subdir
  |   `- module1
  +- module2
  `- moon.work

那么， projects 下的 moon.work 文件可以這樣聲明它所管理的模塊路徑：

members = [
  "./subdir/module1",
  "./module2",
]

當運行 moon check 或 moon build 等操作時，構建系統會嘗試定位當前 workspace，并觸發對其中每個項目的檢查和構建。

如果多個模塊之間存在依賴關系，構建系統會忽略依賴的版本號，優先從同一個 workspace 內的源碼構建依賴。

這對于偏好 monorepo 風格的團隊更加友好，也有助于當前 AI 輔助開發場景下的跨項目協作。

此外，工具鏈還在配置文件中引入了 supported_targets = "..." 約束。社區中的包可能只支持特定后端。例如：

• bikallem/webapi 只支持 JS/Wasm；

• moonbit-community/sqlite3 只支持 Native。

理想情況下，構建系統應該知道每個包支持哪些目標，并在條件不滿足時給出可讀的錯誤信息，而不是拋出一堆來自包內部實現的編譯錯誤。

mooncakes.io 生態

除了工具鏈本身的支持，前后端一體化應用也依賴一組與 Web 開發相關的基礎庫。

MoonBit 的包管理中心已經逐步覆蓋這些能力，包括異步編程、前端 UI、后端服務、數據庫訪問等常見場景。

例如：

• async ：MoonBit 的基礎異步庫，提供 fs 、 process 、 http 等 API。

• rabbita ：前身是 rabbit-TEA，一個函數式、單向數據流前端框架，已經用于構建 mooncakes.io 和 MoonBit 官方網站。

• sqlite3 ：輕量級的 SQLite3 底層綁定。

• webapi ：類型安全的瀏覽器 API 綁定，由 WebIDL 自動生成，覆蓋范圍較廣。

• luna ：一個基于 signal 的響應式 UI 庫，采用 islands 架構。

• mocket ：一個支持 JavaScript 和 Native 后端的 Web 后端庫。

其中， rabbita 、 async 、 sqlite3 等庫都有 MoonBit 團隊參與維護，其接口設計也更符合 MoonBit 的最佳實踐。

可以看到，MoonBit 前端應用已經進入生產環境，后端開發用例也在逐步演進。

下面的示例中，我們將選擇其中一些庫來構建一個簡單的 Todo 應用，用同一種語言實現前端和后端邏輯，并盡可能共享代碼。

前后端一體化實踐

我們從一個最小項目開始。

為了同時支持前端和后端，并盡可能共享代碼，項目被拆分成三個模塊：

isomorphic-template
  ├── backend
  ├── frontend
  └── shared

這種劃分是為了解決一個實際問題：前端和后端需要運行在不同環境中，但我們仍然希望它們盡可能使用同一套業務邏輯。

接下來，我們先從 shared 模塊開始。

共享代碼與領域模型

在這個項目中，前后端共同使用的數據結構都放在 shared 模塊中：

// in isomorphic-template/shared/data.mbt
using @json { traitFromJson }


 pub(all) structTodo {
  id : Id
  content : String
} derive(Debug, Eq, ToJson, FromJson)

這個定義本身并不復雜，但它有一個重要作用： 前端和后端直接使用同一個 Todo 類型。

derive(ToJson, FromJson) 會自動為 Todo 生成 ToJson 和 FromJson trait 的實現。

當后端返回響應時， json_value(...) 會依賴 ToJson 將 Todo 轉成 JSON；當讀取請求體時， event.json() 會依賴 FromJson 將 JSON 還原成 Todo 。

這樣一來，前后端共享的不只是字段定義，還包括圍繞這個類型生成的序列化規則。

只要 Todo 定義保持一致，API 傳輸的數據格式也會保持一致，不需要分別在前端和后端維護轉換邏輯。

有了這層基礎之后，我們再來看后端實現。

用 MoonBit 編寫 HTTP 服務和數據庫層

在后端，我們使用 crescent 中的 Mocket 構建 HTTP 服務，并使用 sqlite3 存儲數據。

整體風格與常見 Web 框架沒有太大差異，邏輯主要圍繞路由組織：

using @crescent { type HttpResponse, type Mocket }


 fn main {
  ...
  let app = Mocket()
  app.get("/api/todo", _ => HttpResponse::ok().json_value(store.list_todo()))
  app.post("/api/todo", event => {
    let todo : @shared.Todo = event.json()
    HttpResponse::created().json_value(store.create_todo(todo))
  })
  app.delete("/api/todo/:id", event => {
    store.delete_todo(event.require_param_int("id"))
    HttpResponse::no_content()
  })
}

這里最值得注意的是數據如何流動。

crescent 會在 API 上添加 FromJson 和 ToJson 的 trait 約束。請求體可以直接被解析為 @shared.Todo ，返回值也可以直接使用同一類型的集合。

整個過程中沒有引入額外的數據結構，也不需要手寫序列化邏輯。具體調用哪套序列化邏輯由靜態類型決定，不會帶來額外的運行時分發開銷。

數據庫層只提供數據讀寫能力。我們用一個簡單的 Store 對它進行封裝，讓 API 始終圍繞 shared 中定義的類型展開。

Store 本質上只是一個持有長期數據庫連接的結構體，并基于 sqlite3 提供的 Connection::prepare 方法封裝幾個 SQL 查詢：

struct Store {
  conn : @sqlite3.Connection
}

 pub fn Store::new(db_path : String) -> Store {
let conn = @sqlite3.Connection::open(db_path)
  ... // Omit the table initialization process
  Store::{ conn }
}

 fn Store::list_todo(store : Self) -> Array[@shared.Todo] raise {
let stmt = store.conn.prepare(
    "SELECT id, content FROM todo ORDER BY id ASC",
  )
letitems = []
while stmt.step() {
    items.push({
      id: stmt.column(index=0),
      content: stmt.column_blob_as_string(index=1),
    })
  }
  stmt.finalize()
items
}

 fn Store::delete_todo(self : Self, id : @shared.Id) -> Unit raise {
  self.conn
  .prepare("DELETE FROM todo WHERE id = ?")
  ..bind(index=1, val=id)
  ..step_once()
  .finalize()
}

由于 sqlite3 是相對底層的綁定，使用方式也比較直接。感興趣的讀者也可以嘗試社區中已經出現的 PostgreSQL 或 ORM 相關庫。

受篇幅限制，本文暫時使用這個簡單封裝。

用 MoonBit 編寫前端

前端部分，我們使用 Rabbita 作為 UI 框架。

Rabbita 是一個受 The Elm Architecture 啟發的 UI 庫，下文簡稱 TEA。

TEA 范式對現代 Web 前端狀態管理設計產生了很深的影響。我們不僅可以在 Redux 以及各種前端生態變體中看到它的影子，也能在瀏覽器之外的 UI 庫中看到類似范式，例如 Iced 和 BubbleTea。

TEA 將 UI 更新拆分為幾個核心部分：

• Model 表示狀態；

• Msg 表示事件；

• update() 處理狀態變化；

• view() 將狀態渲染為界面。

這種模式的優勢在于，狀態變化之間的關系非常清晰。結合 MoonBit 的模式匹配和類型系統，前端邏輯可以自然地圍繞類型展開，也更便于 AI 輔助生成和修改。

在這個 Todo 應用中，前端的核心狀態是從后端加載的一組 Todo 項：

structModel {
  todos : Vector[@shared.Todo]
}


 enumMsg {
  Refresh
  GotRefreshed(Result[Vector[@shared.Todo], Error])
  Delete(@shared.Id)
  ...
}

接下來， update() 負責將消息轉換為狀態變化，并在必要時返回一個 Cmd ，交給框架執行副作用：

fn update(emit : Emit[Msg], msg : Msg, model : Model) -> (Cmd, Model) {
match msg {
    // Request torefresh todos
    Refresh => {
      let cmd = @http.get("/api/todo").expect_json(r => emit(GotRefreshed(r)))
      (cmd, model)
    }
    // Todo request succeeded
    GotRefreshed(Ok(todos)) => (none, { ..model, todos })
    // Todo request failed
    GotRefreshed(Err(_)) => (none, model)
    Delete(id) => {
      let cmd = @http.delete("/api/todo/\{id}")
        .expect_empty(r => emit(GotDeleted(r)))
      (cmd, { ..model, todos: model.todos.filter(x => x.id != id) })
    }
    GotDeleted(_) => (none, model)
    ...
  }
}

這段代碼展示了 Rabbita 的核心工作流：

Refresh 發起請求，從 /api/todo 加載 todo 列表；請求結果隨后通過 GotRefreshed 回到 update() ；如果請求成功，就更新 model.todos 。

刪除時， Delete(id) 會生成一個 DELETE 請求，同時先從本地列表中移除對應條目。這是一種常見的樂觀更新方式，可以讓界面響應更及時。

界面渲染則由 view() 完成。它根據當前 todos 生成列表，并為每個按鈕綁定刪除消息：

fn view(emit : Emit[Msg], model : Model) -> Html {
  let { todos, .. } = model
  if todos.is_empty() {
    p("No todos yet")
  } else {
    ul <| todos.map(todo => {
      li <| [
        p(todo.content),
        button(on_click=emit(Delete(todo.id)), "delete")
      ]
    })
  }
}

到這里，前端邏輯同樣圍繞同一個 Todo 類型展開：

后端返回 Todo ，前端接收 Todo ，UI 渲染和事件處理也基于 Todo 。

這正是 shared 模塊在前后端一體化開發中的價值。

總結

本文通過一個簡單的 Todo 應用，介紹了如何用 MoonBit 編寫前后端一體化應用。

這個示例的重點并不在 Todo 應用本身，而在于： 前端和后端如何在保持運行環境分離的同時，共享同一套業務模型。

通過 shared 模塊，數據結構、序列化規則和校驗邏輯可以被集中定義。通過多編譯目標，后端可以運行在 Native 環境中，前端則可以編譯到 JavaScript 或 WebAssembly，從而讓兩端分別適配自己的運行場景。

這與傳統的服務端模板渲染不同。模板渲染通常以服務端動態生成頁面為中心。但隨著應用不斷增長，搜索、聯動表單、前端即時響應、開放 API 等需求會逐漸把邏輯分散到不同地方。同一條業務規則可能出現在多個位置，從而增加前后端不一致的風險。

MoonBit 的全棧工作流嘗試在前后端分離的基礎上減少這種割裂：它讓前端和后端共享核心業務定義，同時保留各自運行環境的優勢。

如何進一步打磨這套工作流、降低工程復雜度，并更充分地釋放 MoonBit 多目標編譯能力，仍然值得繼續探索。

我們也歡迎感興趣的讀者加入 MoonBit 社區。

MoonBit 官網

https://moonbitlang.cn

mooncakes.io

https://mooncakes.io

使用 WASM / JS 混合編譯目標的真實社區項目

https://github.com/CAIMEOX/symweb