無後端（noBackend）：前端優先的Web開發

每一個應用都由兩樣東西構成：該應用獨有的功能和全部應用共有的功能，比方說用戶註冊、登陸、忘記密碼等。而從用戶的角度出發，那些獨有的功能歸結起來就是用戶界面以及系統的行爲模式。而在視覺表象以後的功能，用戶並不關心，他們只指望系統能按預期運行就能夠了。

前端和後端有各自的側重點，所以每每也須要不一樣的技能，由不一樣的開發人員來負責完成。無後端（noBackend）的開發原則可以進一步解偶這些不一樣的側重點，這樣兩邊的開發人員能夠更加專一於各自真正熱衷的工做。

一個簡單的例子

後端常常須要提供API給前端，如下是一個簡單的例子，使用API進行用戶登陸。

POST /session
{ "email":"joe@example.com", "password": "secret"  }

前端的開發人員須要負責發送上述請求並對結果進行響應，還要考慮到一些極端的狀況，如失去鏈接或不可預知的服務器錯誤等。與此相反的是，無後端的設計原則則建議由前端開發人員來定義API，用前端的代碼來描述後端的功能，舉例以下：

signIn( 'joe@example.com', 'secret'  )
.then( showDashboard  )
.fail( showError  )

咱們稱此爲夢幻代碼（Dreamcode），由於這些代碼常常是在真正的代碼可運行之前就已經寫好了。初一看，這樣並無多大意義，只不過是改爲了發送AJAX請求並調用相應的回調函數而已，可是以這樣的方式定義的API在許多方面都會更增強大：

1. 靈活

用戶若是想要登陸，那麼他們也就只關心登陸這個行爲自己，而毫不會去關心：

• 請求是不是送到應用的服務器仍是一箇中央的驗證服務器
• 是一個HTTP的POST請求仍是PUT請求。
• 是不是經過websocket發送的
• 驗證使用的cookies仍是使用session ID或者是自定義的header
• 應用是否會在前一個請求時後再次發送請求

signIn這個方法的實現能夠進行調整以反映後端的變化，可是就這個API自己，前端開發人員並不須要去修改了。

2. 簡潔

從前端開發人員的角度來看，實現signIn方法要簡單的多，代碼量也能夠少不少；而從後端開發人員的角度來看，儘管剛開始要投入更多的精力，可是和 RESTful API相比，前面的API要更容易定義，文檔化和測試。

3. 前端驅動

前端開發人員能夠引領構建應用的整個設計流程。以Dreadcode的方式來描述後端的功能，可讓開發人員更加專一於用戶體驗，從而避免了因爲討論具體的實現細節而有所分心，也不會因爲要等待後端API的實現而拖延項目的進度。

一個更加複雜的例子

當你研究一個更復雜的例子之後，前優點會顯得更加明顯。假設你想要發送一封郵件，要附上當前頁的PDF。

sendEmail({
  subject: "Hello, World!",
  text: "This mail has been sent from the frontend",
  html: "This mail has been sent from the frontend",
  to: "joe@example.com",
  attachments: [
      convert( document.body  ).to("report.pdf"),
  ]
})

要讓這段代碼跑起來，而且要讓它不受垃圾郵件的影響，可能會至關困難。可是至少能夠立刻寫一些quick和dirty的實現，而後再一點一點地改進，而在這個過程當中無需改變API。這裏的關鍵點在於，前端開發人員能夠把這當作是一個已有的功能，從而能夠專一於用戶體驗，而不須要去關心後臺開發人員到目前爲止究竟有多麼複雜地實現了這個功能。

現有的一些 noBackend 的解決方案

一個nobackend的解決方案應該提供一個前端的API來處理一些通用的後端任務，至少應該包括用戶驗證、數據持久化和同步等。如下是一些能夠關注的方案：

• Backendless
• deployd
• Firebase
• Hoodie
• Kinvey
• Parse
• remoteStorage
• Sockethub

也能夠參考下：unhosted。以上這個列表中，絕大多數都是託管服務，對於想要用本身的服務器來託管的同窗，能夠選擇開源的deployd。

---

原文：Welcome to noBackend!
轉載自：伯樂在線 - 華銘