1樓：o歸隱情緣
重慶我不清楚，但是大部分地方對初級前端需求都不大，一般都是需要有實際開發經驗，能使用一些熱門框架如vue、angular、 react等，對http協議，api介面等比較熟悉，能直接上手開發的前端。至於前後端分離，一般為了方便**的維護和開發能同時進行，前後端分離是一個很好的開發模式，大部分的公司都是採用這樣的開發模式的。
2樓：她們說很棒
重慶這個城市正在大力發展，非常有潛力。重慶的it行業我接觸過，目前還在起步階段。如果你是人才，肯定不會被埋沒的。
前後端分離，前後端工作量比例大概多少
3樓：喬木
一般前端的工作時間會是後端 2 倍左右，後端純資料好寫，前端要調整 ui 的效果等很花時間
4樓：匿名使用者
你說錯了吧，後端的業務邏輯很複雜的情況下，還要考慮效能和大資料的情況下，後端的開發時間要是前端的2倍
前後端分離的前端是怎麼部署到生產環境中的，直接通過 nginx 嗎
5樓：愛笑的柯南推理
front-end-separate(前後端分離腳手bai架)
dufront-end-separate
一個前後端分離的zhi腳手架工具（自主研發）dao為什麼選擇
純粹的前後端分離是必需的嗎
6樓：匿名使用者
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全ajax，使用angular或者什麼什麼就可以了。
這個說法是不合適的，打個比方，別人問的是「如何解決家禽把蛋生在水草邊的問題？」，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答「不讓去水邊就行了」，這顯然不在點子上。
這兩年業界說的前後端分離，是限於偏展示類的系統（用a代替），而不是應用、管控類web專案（用b代替），在b類專案裡，前後端是天然分離的，對此，除了
少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是隻做b類專案，在b類專案裡，前後端分離是共識，不需要討論。
那麼，剩下的問題就是討論a類專案的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與資料結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：
模板應當由前端人員去控制，主要原因有兩方面：
- 效能優化（尤其是外部資源的管理與釋出，請求合併等等）
- 協作的順暢性（已形成模板的介面片段的返工等問題）
那麼，模板到底應該在什麼地方跟資料結合？
這個問題就比較折騰了，有部分人嘗試像b類專案那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏效能不夠，尤其對於首頁dom量很大的電商類**，差距很明顯。
所以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入node層，在這一層把模板與資料進行合成，然後瀏覽器拿到的就
是生成好的html了，但也不是所有html都是這麼生成好的，還是會有一些內容等到了瀏覽器之後，再用js去載入和生成。
所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。
至於說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web專案的東西都可以，這個還是要看所在企業的技術積累方向，當然node
做這塊是有一些優勢的，比如對前端人員的語言友好性，前後端模板的通用性等等，但這些都是細節，重點還是整體方案和流程。
這時候回頭看你問題中的這句：
> 前後端分離的意思是，前後端只通過 json 來交流，元件化、工程化不需要依賴後端去實現。
我相信你這裡對前後端的限定是以瀏覽器為準的，但事實上，a類專案中，前後端的分界一定要延伸到伺服器端的模板層，也就是在這一層裡，把各種**的資料整合到模板中，這個資料未必是json格式的，會存在有json，xml，特定的二進位制等等。
元件化這個話題就更復雜了，在剛才組織形式中，很難說出究竟什麼才是元件。是某個商品的模板嗎？是資料嗎？是資料和模板的結合體嗎？沒法回答。在此，我說一
句自己的看法：像電商這種專案的前端部分，基本不存在元件的概念，甚至不存在元件化的價值，因為這裡面可複用的東西太少了，也不易提取，大多數東西都是不
帶邏輯的介面模板。
最近因為reactjs的流行，帶來了一個isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問
題，尚不得而知，根據我的理解，它對b類專案是較好的補充方案，但對a類專案暫時還缺乏可用性，因為a類專案中，執行期的dom變更並不多，多是整片的改
變，用這個方案去解決的話，有些牛刀殺雞的感覺。
關於b類專案的元件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
前後端完全分離的嗎
前後端分離，關於介面文件，後端是要先寫好介面文件，再進行寫**開發，還是寫完**後再編寫介面文件？ 50
7樓：為人愛兮
1、先理清業務流程
2、定義前後端開發的介面規範。比如json的格式，url的格式3、定義介面文件，這裡的介面文件一般就是對應後臺的實體reqvo（呼叫後臺介面《控制器》訪問的實體）和返回給前臺的respvo（前臺呼叫介面的返回的實體）。注意一般respvo都會有在後臺做一個統一的處理為resultvo（這個規範在2中要定義好，比如：
錯誤碼，錯誤描述，請求的url，請求時間，以及實體t《這個實體才是真正的respvo和業務相關,這個一般都是實體》）
4、定義介面文件是在瞭解業務流、資料流基礎之上完成的。有了這個介面文件（其實就是定義實體的過程和對應的json）前後端的開發基本按照這個文件去開發。介面文件會有版本迭代，一般放到svn上，供所有開發人員閱覽
5、現在一般系統用到的資料庫都不會是單純mysql了。還有redis，mongo、es等。這些個人感覺都是在十分了解業務的情況和系統架構下去設計的。
後臺運用這些工具去完成介面功能的實現已經系統功能和效能的實現。這個和介面文件先後順序還真不好說，個人覺得都可以。
6、業務流-資料流-資金流。去了解和設計系統。
8樓：匿名使用者
兩種方式都是可以的,針對不同的團隊有不同的選擇
一般對於需求分析,設計能力比較強,的團隊,推薦使用契約優先的設計模式,也就是先編寫介面文件,規定好介面的 請求型別/引數數量/引數型別/返回結果的格式然後搭建模擬服務,然後前後端分別開發,但是這種方式需要比較高的設計能力,以應對需求的變更,設計時需要考慮的方面很多,適合於成熟的團隊.
如果需求不確定性較高,甚至頻繁變動,上面這種方式,就會有侷限性,頻繁的需求變更帶來的就是頻繁的介面契約變更.會拖慢前後端的開發進度,這種時候可以採用,先開發後編寫文件的流程,由於頻繁的發生變更,這時候團隊的溝通顯得很重要,專案管理人員一定要十分注意前後端開發的溝通效率,不然專案進度會變得不可控
9樓：真的老了玩不動
先設計資料庫，你寫介面就是訪問資料庫，返回 資料庫的資料和自己處理的拼接而成的資料。
再根據返回的資料寫介面文件。例如你少了條件就返回 0 ，成功訪問資料庫並處理 返回1， 其他的什麼情況返回什麼數字。 這些返回的數字，就寫在文件裡，返回什麼，代表什麼意思。
大概這樣子 。
php前後端分離 前端用什麼框架
10樓：押警
隨便唄。這麼關心前端用什麼框架幹嘛。
11樓：不跳主城
vue.......................
前後端分離後，html放**
12樓：猧蝨歋
用框架的話每一種框架放的位置都不一樣，thinkphp裡面是mvc，html放在v（view）裡面
13樓：匿名使用者
mvc放v層，view檢視層！
如何處理好前後端分離的api問題
意義很大，但是你的問題本身認識有偏差。對於前後端分離，認識上有個誤區，那就是很多人自稱 老早就分離了，全ajax，使用angular或者什麼什麼就可以了。這個說法是不合適的，打個比方，別人問的是 如何解決家禽把蛋生在水草邊的問題？但實際上人家養的是鴨子，答題的卻是養雞的，所以回答 不讓去水邊就行了 ...
如何通過nodejs來實現php的前後端分離
nodejs本身就替代了php的後端功能。如果是node來寫restful介面,php呼叫介面並渲染頁面,兩邊把介面定義好,各寫各的。如何通過nodejs來實現php的前後端分離 原本返回html的php,現只返回資料,資料交由node拼接html,node和php必然要http,因為php web...
重慶貸款公司都是怎麼貸款的，重慶貸款公司貸款方式有哪些
綜合客戶資質進行優化貸款組合 之前我的抵押車就是轉給他們的 何133一一一08一一一38一一一52一一一95 有資方和平臺，每個人情況不同，相關利率也是不一樣的。常見的有信用貸，房車抵押貸。正規的貸款公司都不收取貸前費用,保證金,驗證金,保險金各種套路,貸多了,上當了,都有經驗了,反正各種套路讓你先...