為什麼需要SSR而不是SPA
理解為什麼該這樣做，才是對自己寫的code負責任的表現。
相較於SPA (Single Page Application)，SSR有著不少的優勢（Google上查得到的一切），但我認為最重要的是，在server上「預處理」好當下頁面需要的所有資料，然後提升整體web app的效能（performance enhancement）。
所謂的預處理是什麼意思？簡單分成兩個部分，白頁問題跟資料獲取。
白頁問題
白頁問題比較好理解，就是SPA通常只會丟出一個空白的HTML，然後使用者一開始就只能看著空白的頁面等待JS下載跟執行完成，雖然時間通常不會太長，但讓使用者心情不好，就是效能不好，別讓使用者不開心。（參考Google RAIL Model），反而SSR會在server上處理好要渲染的頁面，然後丟給使用者，這樣就不會有等待白頁的問題了。
資料獲取
資料獲取則是另一個會導致使用者不滿的原因，舉個例子來說，今天一個頁面的初始化需要打很多個API，如果使用者的網路烙賽慢…那肯定是個悲劇。但相對於server來說網路是比較穩定的，如果能把這些初始化動作在server上做完，那肯定會是最好的。
不過SSR並不是沒有缺點，對於SSR來說，第一次響應頁面的速度肯定會比SPA慢，因為你需要在server上處理不少東西，而SPA只是簡單的丟個HTML而已。
SSR也讓整個專案的架構變得複雜，開發上的維護成本也比較高，比如說在調用Window API時需要判斷當下是在Sever還是Client環境（註1）。另外還有，專案如果有導入Redux，那也必須面對在server在初始化頁面之前需要dispatch哪些action，以及規劃建立初始state等等問題。（註1：雖然像是Deno好像沒有這個問題，但這只是題外話）
最後還必須去思考，對於專案本身SSR是不是必要的？
成本的考量不該僅僅只是在技術面，現實面也很重要。
舉個例子，如果你的產品是對外的，那效能（performance）肯定是必須考量的重點。但如果今天是公司的內部系統，那為了效能導入SSR似乎就不是必要的，反而會增加更多的維護成本。不是說內部使用者就不是人，但對於內部系統還有其他需要花費精力的地方，比如各種特別客製化的需求等等，效能優化伴隨著一定的成本，效能重要但過度的優化不是好事，除非內部系統有成千上萬的User，那似乎又是另一回事了。
我想睡覺了
最後因為我想睡覺了，有機會再分享實作的部分，感謝耐心讀到這裡的大大們，晚安囉。
想持續關注我的話
去Medium追蹤給他按下去
去Facebook粉專按按讚～
去Youtube頻道訂閱，每週三都直播聊聊大家想問的問題。
加入我創的Line社群，群組目前有1200多人，可以一起進來交流分享經驗跟技術。
Line社群點我加入：https://reurl.cc/V3WjGZ
