在大型網站上平衡服務器端和客戶端代碼

Question

讓我們假設我正在編程Facebook（我不是）或其他一些涉及大量流量的網站。

我們的總體佈局是：

1. 所有的CSS是在外部文件
2. JS的99％是在外部文件
3. 由PHP生成的網站HTML的背部骨/ MySQL後端。
4. JS函數用於生成通常會更改的零件的DOM。
5. 我們的服務器有一個inplace API，它返回提供給我們的DOM構建器（JS函數）的JSON對象，這些JSON對象接受一個JSON對象數組，可以說是朋友列表，然後生成所有用於顯示列表的html朋友，或事件等

問題

，這是否合理？

像我剛纔提到的那樣，通過專用的JS函數來構建DOM？

這是可縮放的嗎？ JS太慢了嗎？ （順便說一下，我們幾乎完全使用JQuery）

我知道它會極大地降低帶寬和服務器負載，因爲服務器不再遍歷朋友列表（它也通過MySQL查詢）並生成所有的HTML，而是做一個查詢並返回一個小的JSON對象。這對我來說似乎沒問題，但我想要第二/第三/第四/ ...個意見。

非常感謝！

讓我知道我是否缺少任何關鍵信息。

Answer 1

我認爲你的佈局很不錯，但我仍然建議你閱讀YAHOO! Best Practices for Speeding Up Your Web Site。它總結得更好（非常好閱讀在我看來）比我能做的更好。

我覺得最重要的三個件事Facebook並實現它的規模：

1. CACHING =>Memcached。這一個非常重要。您應該記住，與磁盤IO相比，磁盤IO速度較慢（根據我的book，磁盤5ms /內存40-80ns）。 Facebook幾乎擁有內存中的所有活動數據。他們說內存中的內存超過5TB。到現在爲止，這將是更多的方式！
2. HIPHOP =>https://github.com/facebook/hiphop-php/wiki/
3. 離線處理 =>使用像例如redis，beanstalkd，gearman僅舉幾一個消息隊列中。

其他一些有趣的環節：很多的快速反應

• http://sizzo.org/wp/talks
• http://www.facebook.com/pages/Scalable-web-architectures/310457196919?v=wall

Answer 2

鑑於JS引擎正在不斷髮展，以提高性能，我認爲這是一個非常好的設計。隨着HTML5 & Co的普及，我們將越來越頻繁地看到它。

Answer 3

這是我正在走向的方法。我很滿意它。 JS當然不會太慢。你會想要一個好的JS模板系統。 Trimpath JS Templates是我嘗試過的那些人的最愛。