求助面試題，如何在項(xiàng)目中做好前后端的分離，具體實(shí)施計(jì)劃是什么樣的？還有ssr渲染

前后端分離，即前端頁(yè)面脫離后端服務(wù)也可以單獨(dú)運(yùn)行。
我從開發(fā)和上線兩個(gè)部分簡(jiǎn)單說一下。

• 開發(fā)

前端開發(fā)不再依賴后端服務(wù)，定義好數(shù)據(jù)結(jié)構(gòu)和接口名稱就可以了。
比如采用restful的模式：前端使用mock，后端使用swagger。
這樣就不會(huì)由一端而影響另一端的進(jìn)度。再者，后端可以同時(shí)支持web、移動(dòng)以及第三方的系統(tǒng)。

• 上線

前后端可以獨(dú)立部署，不再將前端的文件放到后端的服務(wù)中。也可以更好的做負(fù)載等一些運(yùn)維的操作。

再說說SSR，也就是服務(wù)端渲然。目前要在需要支持SEO的情況下，才會(huì)做SSR。

這種面試題我覺的算是開放性的問題了，要仔細(xì)說，東西太多了，如果要是考察的話，可能就是為了考察下實(shí)際工作中是否遇到一些坑以及解決辦法吧，我就分享一些我遇到過的問題以及解決辦法：

• 首先第一點(diǎn)是先考慮項(xiàng)目需不需要前后端分離，如果是重前端類型的項(xiàng)目，比如網(wǎng)盤這種，那前后端分離確實(shí)可行，如果是博客這種內(nèi)容驅(qū)動(dòng)式的項(xiàng)目，就不要前后端分離了，沒什么意義
• 接口返回?cái)?shù)據(jù)格式經(jīng)常會(huì)遇到后端返回的數(shù)據(jù)不是前端所期望的，這種情況下不是后端改接口就是前端做數(shù)據(jù)處理，總之是經(jīng)常會(huì)發(fā)生口角的地方，解決方法有很多，比如提前溝通并設(shè)計(jì)大家都滿意的數(shù)據(jù)格式、做中間層服務(wù)（比較復(fù)雜的項(xiàng)目）、嘗試一些帶 schema 約束的接口規(guī)范，比如 json-restful 或者 GraphQL 等等
• 我理解的前后端分離僅僅是代碼邏輯上的分離，在實(shí)際工作中，還是要多和后端溝通，及時(shí)反饋一些項(xiàng)目實(shí)施過程中的問題，因?yàn)橛行﹩栴}可能前端解決是可以的，有些問題后端解決可能更好，比如像一些權(quán)限方面的東西，最好不要在前端鑒權(quán)
• 緩存我認(rèn)為也是前后端分離中的一個(gè)大坑，這個(gè)就不展開說了，涉及東西太多
• 如果是 SPA 還想在 SEO 上取得一些優(yōu)化的話，還給整 SSR

具體 SSR 渲染的東西，我就不亂說了，因?yàn)檎娴氖呛?jiǎn)單接觸并做過一些小的 DEMO 項(xiàng)目，并沒有真實(shí)線上項(xiàng)目的實(shí)踐經(jīng)驗(yàn)，坑也踩的少。

以上個(gè)人拙見，如有錯(cuò)誤，還望指正。