單一頁面應用程式

(KJH) Kuan-Jung, Huang
5 min readDec 15, 2017

--

總之是把工作丟給別人做

前言

如何把 Server-side 的工作丟給 Client-side,以降低 Server 的負載量,讓一台機器能頂兩台用?

首先 ,要把 UI 的渲染(Render)從 Server-side 移到 Client-side;接著另一個步驟,在 Client-side 實作程式邏輯。

是,今天要介紹 SPA。

SPA(Single Page Application)意思是僅有一個頁面的應用程式,也就是說網頁不需跳轉頁面就可以達到基本的建立、讀取、修改、刪除資料功能。

早期的網頁應用程式

如果學過 MVC 架構的人,可能一開始學習寫含四個功能頁面,即建立、讀取、修改、刪除頁面為底進行網站製作。以往的網頁主要採用「Multi-page」的設計方法,一個功能或一個動作及一個頁面。上述就是此設計方法。

由這張圖,我們可以發現過往的網頁是以 Client Request — Server Response 的溝通方式,一個要求產生一個畫面的模式,來產生網頁的畫面。所以會出現我們前述的網站設計架構,但隨著技術不斷的進步及使用者體驗的追求,我們致力於讓體驗變得更好。

Ajax 以及 REST 服務的知識改變網頁應用程式設計規則

其實我不是很確定這標題是否正確,因為上網看了不少文獻都提及這兩個技術的出現讓 SPA 得以實作,但是沒人把兩個東西放在一起討論,所以我把它歸納為兩個促進 SPA 技術的原因。如果這邊有誤,請告訴我。

時間來到 Ajax 技術成熟, REST 服務的知識興起,有了這些概念,我們現在只需要在第一次傳送 HTML檔以及 CSS 或 Javascript 檔案,其餘資料可利用 Ajax 來要求 XML 或 JSON 格式資料,但是我們不需要重新載入畫面。

那我們只要做什麼?更新部分網頁要載入的內容!所以我們可以用 Ajax 進行某個區塊的更新即可,如下列程式碼所示。

那這邊的 REST 服務扮演什麼角色?首先其是一種設計樣式,而不是 Web 技術,RESTful API 顧名思義是利用 REST 的思維實踐一個系統去存取 API。如果對 REST 不是很了解,可以點我

在 SPA 中,由於需要在不同時間傳輸各種資料,所以採用 REST 的方法可以直接使用 URL 的更改來取得或更新資料。所以在這邊的 REST API 主要是用於資源的存取,假設我有以下的資料希望呈現在前端:

我們想要拿到資料,在 REST 中我們會以這樣的形式表示:

GET /user?name=Kevin

他背後的運作邏輯如下:

我們可以用這個技術再不讓頁面重新載入的情況下,獲得要顯示在前端的資料。

使用 REST API 的好處是易於進行測試,因為使用固定格式的 URL 進行資料存取,我可以利用 Mock 進行單元測試,或者使用 Postman 來測試,所以基於這些好處,現在前端慢慢都在整合 REST API。

SPA 的優缺點

首先提到的就是部份更新。SPA 只有一個頁面,利用 AJAX 來更新部分網頁資料。 改善了過去必須因為一個小地方更新,而使得整個網頁必須重新載入的困擾。這個改變不只是將過去的多個功能,拼成在同一個頁面而已,也考量到使用者的使用體驗 ,除了不必一直跳轉頁面外,讓使用者更輕易地感受到與桌面應用程式一樣的使用感也是一大革新。

而前後端分離的設計模式,後端負責產生計算資料,前端負責頁面的呈現。透過 Client 及 Server 端的區分,讓前後端有更加的職責區分。

不過光明面的背後必有黑暗面, SPA 因為將所有資料放在頁面而非伺服器中,SEO(搜尋引擎最佳化)問題需克服[2]。而且我們因為是使用 AJAX 來傳輸資料,把所有的資料都放在同一個頁面,過程中網址都沒有改變,所以我們必須自訂狀態來判斷資料的傳輸是否成功或失敗[1]。

實作簡介

現行的前端框架的語言多數都支援此種實作方式,包含 jQuery 也可以。唯一差別在於實作上的複雜度不同, Angular 是實踐 SPA 最常被使用到的前端框架語言。

結語

前端的設計與實踐,並不是一定要使用 Single-page 的模式才好,而是必須根據情境來設計,如果以使用者體驗當作主要設計考量,那就可以考量 SPA 架構的網頁應用程式。

參考

[1] 網址仍然可以透過html5的方式做改變。網址的改變與必須自訂狀態來判斷傳輸成功失敗似乎沒太大關係。12/15 2017

[2] 承上,即使網址有變動了,如果別人拿到變動的網址就可以直接看到同一頁。第一次的request做server side回傳完整html。12/15 2017

--

--

(KJH) Kuan-Jung, Huang
(KJH) Kuan-Jung, Huang

Written by (KJH) Kuan-Jung, Huang

CTO at Metablox.co, Founder of AI Users Community in Taiwan

Responses (1)