今天聊：先後端分界線與 GraphQL

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

天下苦先後端協同久矣

過去一年多太多同窗問我對於 GraphQL 的態度，就小小做文一篇，瞎聊一下。

先後端，從十幾年前開始明確的分化，不管前端後端，到如今都經歷了太屢次的技術變遷，多少程序員黑髮到白髮，長髮到禿頭沉沉浮浮，先後端現在的邊界在哪裏，咱們大腦皮層遇到這個問題的第一個反應，每每就是，前端開發頁面，服務端渲染頁面或者與頁面異步同步數據，剩下的事情就交給瀏覽器了，邊界彷彿就在靜態頁面開發和數據渲染這裏，那麼它真的是在這個地方麼？

要回答這個問題，先聊一聊個人職業生涯，我從事前端開發快 10 年了，算是一個老前端，在個人眼中，前端後端的邊界愈來愈模糊了，並且這個邊界也在不一樣的公司，不一樣的團隊，甚至不一樣的業務模式下，不斷的發生着變化，這不是廢話麼，那到底邊界線哪裏，是什麼？

我我的以爲，就是數據的控制權和與視圖所依賴的 API，這裏就是目前先後端的邊界，數據控制權屬於後端，API 屬於後端，把先後端簡單看作是一個完整的系統，這個系統中自 API 向下天然是後端的，API 向上則慢慢屬於前端，爲何是慢慢屬於前端，先後端的職能變化，先後端的分工邊界，先後端的角色變遷，都跟咱們這一次以 GraphQL 爲表明的數據方案有着密切的關係。

不過話說回來，雖然 Scott 從業已久，但這個問題依然是回答的戰戰兢兢，緣由就在於對於技術方向的判斷，大多數資深的工程師都會有類似的判斷，但對於某一層或者某一塊具體的技術實現方案，你們得出的結論會相差甚遠，這個有一小部分是人的問題，好比技術視野，技術胸懷，技術背景，以及我的的職業規劃，但大部分是客觀環境的問題，咱們老是站在本身熟悉的若干客觀環境下，以此舉例和類推，得出整個世界也基本上是相似的狀況相似的運做模式這樣的結論。

其實不一樣公司不一樣團隊甚至不一樣風格的工程師組合在一塊兒，是徹底沒辦法經過理論推導來達成統一的，因此我須要再次重申一下，GraphQL 有多是不能解決你當下甚至將來的團隊合做效率、開發模式問題的，可是它必定會給你帶來一些不一樣的視角來認識到兩件事情：

• 第一個，先後端的合做成本其實很高，源於語言棧源於主導權，也源於各自職能的不一樣，這個是必然的，即使是有了各類的 Mock 方案，團隊規範，工具基建，都沒辦法大幅度的下降這個成本。
• 第二個，先後端的邊界既不像咱們認爲的那麼清晰，先後端的職能壁壘也不像咱們認知中的那樣不可逾越，他跟咱們心裏對本身的工程師身份認同有很大的關係。

因此你們要問本身一個問題，爲何我必定是一個前端工程師，爲何我必定是一個後端工程師， 爲何我必定不想去關心任何系統底層或者上層 UI 的問題，爲何我以爲端上的體驗和頁面或者服務搭建，幾乎是我工做的所有重心，爲何做爲前端，每每會以爲上線那一刻起本身的工做就已結束。

這一二十年先後端技術演進的過程當中，先後端各自的能力邊界都獲得了很大的擴展，互相合做纔有了今天互聯網的繁榮，我我的的角度是，前端後端的邊界模糊也好，清晰也罷，本質上咱們是一個系統的上下組合部分，經過各類咬合來保證產品正常上線運行爲公司創造價值。

至於咱們咬合的部分，是須要雙方都有足夠的勇氣和胸懷，邁出一步甚至兩步，以團隊效率爲根本出發點，而不是僅僅職能，前端工程師儘可能不要限定本身的界限，能夠放大本身的能力甚至是權利，主動承擔灰色地帶的事情，這些事情的承擔看上去是苦活累活，但最終解放的依然是咱們本身的價值枷鎖。

說的有點玄乎，一句話收尾，先後端在變化，邊界也在變化，不管先後端都應該開放心態，調研新工具，實踐新方案，站在一塊兒來讓工程師的技術價值最大化，幫公司省更多錢，給公司賺更多錢，這個須要決策者的心胸格局和專業度。

這個邊界到底如何變化呢，我認爲截止到目前，GraphQL 是一個可小範圍嘗試的解決方案，它能解決問題也同時帶來挑戰，你們用的時候要當心慎重，而這兩年大火的 Serverless，它也有它特殊的生存環境，咱們依然能夠用 open 的心態看待，小範圍試用的嚐鮮，但具體到生產環境，咱們依然要當心慎重。

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬扛，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream，也能夠來 關注 Scott 語雀跟進最新動態，本文未經許可不準轉載，得到許可請聯繫 Scott，不然在公衆號上直接轉載，尤爲是裁剪內容後轉載，我都會直接進行投訴處理。