2013-05-06 73 views
1

我要創建一個全新的網站,並從頭開始編寫所有內容,主要是前端部分。我只想知道是否有任何資源構建可擴展的前端架構,因爲我之前從未有過這種體驗。任何建議,想法或書籍推薦將不勝感激!構建可伸縮前端體系結構的任何資源?

+1

可伸縮前端?通常前端(我指的是這裏的客戶端,例如瀏覽器)不需要擴展超過1個用戶。也許我錯過了一些東西。 – 2013-05-07 14:50:08

+0

我真正的意思是,因爲我需要編寫大量的JavaScript文件,所以如何在大型網站中構建這些js文件? – chaonextdoor 2013-05-07 16:35:08

+0

如果您打算在客戶端使用框架(我會建議如果您不打算),那麼它只是在interwebs上搜索人們所做的事情。對於例如對於AngularJS,種子應用程序模板(https://github.com/angular/angular-seed)效果很好。如果你沒有使用框架,那麼它將不可能回答你的問題,因爲它將取決於你如何設計你的前端(mvc,mvvm等)。 – 2013-05-07 18:19:49

回答

2

很難回答你的問題,因爲我們不確定它的每一個部分。據我所知,沒有像「可擴展前端架構」這樣的定義。無論可擴展前端是非常廣泛的話題,所以我只能猜測...

我在你的條件承擔前端意味着單頁JavaScript應用程序可擴展部分意味着功能可伸縮性(而不是負載可伸縮性通常在服務器端上下文中使用)。有了這些限制,我認爲REST架構是我所知道的最佳匹配。

  • 由REST架構有REST服務和REST客戶端。兩者都是應用程序您可以在瀏覽器中運行REST客戶端作爲前端應用程序,並且可以在服務器上運行REST服務作爲後端應用程序。 REST專爲HTTP 1.1協議而設計,因此您可以看到它可以輕鬆適應HTTP客戶端和服務器的常規上下文。

  • 常規Web服務僅向其客戶端提供數據(例如以JSON格式),客戶端應該知道如何處理它。所以客戶端必須包含業務邏輯的片段。該服務也包含業務邏輯,因爲它是檢查請求有效性的唯一安全環境,並且只有它才能訪問常見的持久性存儲(數據庫)。因此,在這種情況下,服務和客戶端都包含相同的代碼片段,因此,Web應用程序的代碼不是DRY。我猜你已經知道非DRY代碼很難維護......通過REST架構,服務不僅發送數據,而且還向客戶端發送抽象控制器(鏈接和表單)的表示。這可以通過發送任何超媒體格式來完成。如果您認爲HTTP通信的做法相同,它會以HTML格式發送控制器和數據表示。我們可以使用HTML作爲消息格式,但不建議這樣做,因爲解析它很困難而且速度慢,並且沒有任何關於如何以HTML格式序列化數據的建議。 XML和JSON不同,它們是爲數據序列化而設計的,但它們缺少控制器描述。目前有許多基於XML和JSON構建的新出現的超媒體格式,它們能夠實現:ATOM + XML,HAL + XML,HAL + JSON,JSON-LD,警笛(JSON),集合+ JSON等等......

  • 因此,您的REST客戶端從REST服務獲取超媒體格式的數據和控制器表示。例如,通過個人資料頁面,您可以獲得一個姓名,出生日期等......作爲數據和編輯表單,刪除鏈接等...作爲控制器。目前很少有標準/建議如何描述控制器。您可以瞭解我提到的媒體類型或製作自己的媒體類型。它並不那麼難......重要的是,REST客戶端在獲取它們之前不應該知道確切控制器的任何信息。它只能知道如何顯示它從服務中獲得的控制器。例如,通過註冊表單,它不應該知道URL的方法,輸入字段的名稱等等,但它必須知道如何顯示當前超媒體格式中描述的註冊表單。瀏覽器也是這樣做的,他們將表單作爲HTML FORM元素使用,儘管事實上他們對於將填充表單發送回服務器時會發生什麼事情一無所知,但他們獲得了格式很好的表單。因此,瀏覽器對他們正在顯示的Web應用程序的業務邏輯完全不瞭解。 REST客戶端與REST服務相同,他們對REST服務的業務邏輯一無所知,他們只知道如何顯示REST服務發回的超媒體,以及如何向服務發送請求。這是一種容易理解的方法,我認爲......由於這種設計方法,REST客戶端和REST服務是鬆散耦合的,容錯和易於維護。例如,如果你添加新的功能,例如您的REST服務的新鏈接,它通常不會影響你的休息客戶,因爲他們已經準備好處理鏈接...

我認爲這是很容易瞭解REST架構的理論,但是技術訣竅要困難得多。它引起了很多混淆,人們經常將他們的常規Web服務稱爲REST服務,因爲REST架構現在是一種炒作。每個人都希望這樣做,但他們中很少有人做得對...