<b>本文講的是為什麼我們要用網頁端元件去建構伺服器？該怎麼做？，</b>
Web components（網頁元件）用在伺服器端渲染早已被大家所了解，在本文中，我想談及的是：你還可以用 web components 建構伺服器端應用。
聲明式
子產品化
通用化
可共享
可調試
更平緩的學習曲線
用戶端結構
現在你可以使用 HTML 文法來聲明路由了。比起純 JavaScript 文法，現在的路由可以展現出視覺層次感，看起來更加形象和易于了解。拿上面的例子來說，所有和 Express 架構有關的 endpoints(路由) / middleware(中間件) 都嵌套在 <code><express-app></code> 元素，連接配接 app 的中間件按順序放在 <code><express-middleware></code> 元素中。而路由也可以很容易地嵌套，<code><express-router></code> 中包含的每個中間件都會連接配接到 router，你還可以把 <code><express-route></code> 放在 <code><express-router></code> 元素中。
<code>index.html</code> 是入口檔案，實際上我們需要關心的地方隻有一個，就是 <code><na-app></na-app></code> ：
我們啟動 Express 應用，監聽 port <code>8080</code> 或者 <code>process.env.PORT</code> 端口，然後定義了三個中間件和一個自定義元素。希望你直覺上就能了解那三個中間件會在<code><na-api></na-api></code> 之前運作的工作原理：
所有 <code><na-api></na-api></code> 的内容都包裹在 <code><express-router></express-router></code> 當中。元件裡的所有中間件都在通路 <code>/api</code> 時生效。接下來再看看 <code><na-bears></na-bears></code> 和 <code><na-bears-id></na-bears-id></code>：
如你所見，所有路由都被分離到各自的元件中，并且要包含在 app 中也很容易。在 <code>index.html</code> 檔案中的 import 引入方法非常淺顯易懂，
我喜歡 JavaScript 的原因之一，就是可以在用戶端和伺服器端共享代碼。雖然現在某種程度上可以說這是可行的，但實際上，由于某些 API 的缺失，依然有一部分用戶端的庫不能在伺服器端工作，反之亦然。從根本上說，Node.js 和浏覽器依然是提供不同 API 的兩套環境。那有什麼辦法可以結合呢？我們想到了 Electron，Electron 把 Node.js 和 Chromium 項目結合成為一個單獨的運作環境，使得用戶端代碼和服務端代碼結合運作成為了可能。
我隻需要導入這個庫，無需任何代碼改動，就順利在服務端運作起來了！
Electron 和 Scram.js 提供了 LocalStorage, Web SQL 和 IndexedDB，使得 localForage 成為了可能。我們就這樣搭建起了一個簡單的伺服器端資料庫！
雖然我不确定怎樣測量其性能，但至少這個方法是可行的。
這點完全得益于 web components，因為 web components 的其中一個主要目标就是使得元件易于共享，實作跨浏覽器通用，并停止在同一個問題上因為架構或者庫的改變而不斷重複實作。共享之是以變得可能，是因為 web components 基于現有的或者提出的标準，所有主流浏覽器的廠商都會想辦法去實作。
這意味着 web components 不依賴于任何架構或者庫，就可以在任何 web 平台上通用。
我希望有更多人能參與到建立伺服器端 web components 的建立當中，并把各種功能打包成元件，就像前端元件那樣。我從 Express components 開始了這項工作，但我還期待看到 Koa, Hapi.js, Socket.io, MongoDB 等元件的出現。
Scram.js 有一個 <code>-d</code> 選項，讓你可以在調試時打開 Electron 視窗。現在你可以使用 Chrome 開發者工具的所有功能來幫助你調試伺服器了。斷點、控制台日志、網絡資訊等都可以在裡面看到。Node.js 的服務端調試似乎總是我的第二選擇，但現在它的确已經內建到了平台中：
服務端 web components 對降低後端程式設計學習難度有幫助。要知道有很多 web 設計師、互動設計和其他一些隻懂 HTML 和 CSS 的人希望學習服務端開發，但現有的伺服器端代碼對于他們而言很難了解。然而，如果使用他們熟悉的 HTML 來編寫，特别是用上語義化的自定義元素，他們就能更容易地上手伺服器端程式設計了。至少我們可以降低他們的學習曲線吧。
用戶端和服務端 app 的架構正變得越來越像了。每個 app 以 <code>index.html</code> 檔案開始，然後引入相關元件。這隻是一種新的統一前後端的方法。在過去，我覺得想要找到伺服器端應用的入口多少有點困難，如果後端能像前端應用一樣，以 <code>index.html</code> 作為标準的入口，不是挺好的嗎？
以下是使用 web components 建構的用戶端應用的一般結構：
以下是使用 web components 建構的服務端應用的一般結構：
這兩種結構應該都可以很好地工作，現在我們成功減少了從用戶端到服務端切換的上下文數量，反之亦然。
Electron 在伺服器生産環境中的性能和穩定性，是最有可能導緻應用崩潰的原因。話雖這麼說，我并不覺得性能在将來是一個大問題，因為 Electron 隻是通過一個渲染程序運作 Node.js 代碼，我猜想和原生 Node.js 的運作狀況差不多。最大問題是，Chromium 的運作時能否足夠穩定，堅持運作足夠長時間（而不發生記憶體洩露）。
另一個潛在問題是備援性，相比原生 JavaScript 邏輯，使用服務端 web components 完成相同任務會花費更多時間，因為标記語言需要解析。話雖這麼說，我依然希望付出備援的代價，能換來更容易了解的代碼。
在本地機器上運作
每秒遞增 100 次 GET 請求
運作直到有 1% 的請求傳回不成功
對于 Node.js app 和 Electron/Scram.js app 版本，分别運作 10 次測試
Node.js app
使用 Node.js v6.0.0 版本
使用 Express v4.10.1 版本
Electron/Scram.js app
使用 Scram.js v0.2.2 版本
預設設定（從本地伺服器加載起始 html 檔案）
調試視窗關閉
使用 electron-prebuilt v1.2.1 版本
運作指令: <code>nab http://localhost:3000 --increase 100 --verbose</code>
以下是結果 （QPS: Queries Per Second 每秒查詢數）：
出乎意料，Electron/Scram.js 比 Node.js 性能更佳。我們對這個結果持保留意見，但起碼還是能反映出使用 Electron 作為伺服器的性能不會比 Node.js 差很遠，至少在短期内處理原始請求的效果是如此。還記得我之前說過“我并不覺得性能在将來是一個大問題”嗎？結果證明了我的描述。
Web components 很好很強大，給 Web 平台帶來了标準化、聲明式的元件模型。Web components 不僅能給用戶端帶來便利，而且在服務端也獲益良多。用戶端和服務端之間的差距正在縮小，我相信伺服器端 web components 是正确方向上的一大邁進。是以，一起來使用它們建構我們的應用吧！
<b></b>
<b>原文釋出時間為：2016年08月02日</b>
<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>