當前端把手伸向後端,做起全棧時

語言: CN / TW / HK

連結

本次內容來自內部的一些課題分享,也非技術性的內容,只是淺談一下作為前端如何“卷”起來罷了。

首先是我們都從事著前端開發的工作,也會每天和產品、設計、後端、測試、運維等產品生命週期內的成員們打交道。

那麼什麼被稱作是“全棧”呢?

從知乎上我看到一句內容我挺贊同的,全棧就是一個通才,能夠自己建立不平凡的應用程式。

很關鍵,其實會和你看到這次分享時的想法有點不太一樣,只是在定義全棧這件事情的角度發生了變化。

從廣義上來說,全棧就是一條龍服務,即使用者提出了一個應用程式的需求,全棧能夠獨自設計並交付這個應用程式來滿足使用者的需求。

可以說是包攬了整個應用程式產品的生命週期,樣樣精通。

但是我們今天也不會討論的這麼廣,那麼回到正題。

從軟體開發的角度來說,即前端+後端可以產出一個應用程式,前端也就是我們俗稱的切圖仔,也就是我;後端是我們俗稱的業務仔。

那麼有了如此淺顯的認識後,我們該如何從前端出發,把手往後端伸過去,做起一個全棧開發工程師呢?

其實我們可以慢慢的伸過去,我們來回憶一下。

我們與後端互動頻率最高的操作,那必定是 HTTP 請求,通俗寬泛一些的講就是 AJAX 。

在工作多了其實會發現 RESTful 這種架構並沒有真正意義上的方便我們的互動,它也有它的問題。

那麼這時候喜歡“卷”的我們就設計了一套中間服務,美其名曰 BFF 。

其實 BFF 可以算是我們伸向後端的第一步,首先跟我們的後端同學分析現狀,業務仔每次因為一個特殊的需求或者場景需要給我們增加一個 API 介面真的很心累,作為業務仔才不想關心這些呢。我們的後端同學表示只想專心於業務,那麼我們“卷”的機會就出現了。

這時候後端同學通常會暴露出一些具備通用性且抽象的 API 介面,至於我們想如何使用,我們則在 BFF 進行自行定義,那麼如果遇到上面的問題,我們也不需要苦苦的去求後端同學增加 API 介面,後端同學也可以跟切圖仔說拜拜了。

當然了,BFF 中間的實現過程依然可以是 RESTful to RESTful 的形式,也可以是 GraphQL to RESTful 的形式,前者有後端控制,我們 BFF 只做中間的轉換者。

慢慢的,你會發現後端沒有心思來管業務,他們更多的會去關心一些底層的設計和效能問題,那我們就可以既是切圖仔又是業務仔了,這時候的後端為我們提供可以是一些由後端給出的操作資料的介面、或者直接操作資料庫的許可權,那麼這時候我們就是名副其實的業務仔了。

再慢慢的,我們就把手伸到那些底層的設計和效能問題時,後端就不復存在了……(開玩笑的)這是不可能的。

當然了,對於前端……啊呸!軟體開發工程師來說,熟悉並掌握整個軟體開發的細節,這時候就是全棧了!

自身能力也得到了提升,可以說是卷王之王!

當然了,我覺得接觸後端不一定是要做個業務仔的,也可以從應用程式優化的角度著手。

比如我們前端常說的 SSR ,優化應用程式在客戶端的啟動時間,也會讓你接觸到後端的技術。

優化 DevOps 流程、縮短編譯時間等等優化方向都會讓你接觸到後端技術,只是作為前端,其實身邊有很多機會可以把手伸到後端去,所以大膽伸進去試一試吧!

當然從此發散出去,也可以把手伸向產品設計、視覺互動設計、軟體測試、軟體運維等各個環節中去……卷他們。