JavaScript >> Javascript 文檔 >  >> Node.js

Node.js 和新的 Web 前端

前端工程師在軟件工程方面有著相當悠久而復雜的歷史。在最長的時間裡,你發送到瀏覽器的東西“足夠簡單”,任何人都可以做到,並且沒有真正的專業化需求。許多人聲稱,所謂的網絡開發人員只不過是使用不同媒介的圖形設計師。有朝一日您可以專攻 HTML、CSS 和 JavaScript 等 Web 技術的想法充其量是可笑的——畢竟,UI 是任何人都可以拼湊起來工作的東西。

JavaScript 是真正開始改變 Web 開發人員觀念的技術,將他們轉變為前端工程師。許多軟件工程師不屑一顧的這種古怪的小玩具語言成為了互聯網的驅動力。隨著更多瀏覽器的引入,CSS 和 HTML 隨之而來,造成了跨瀏覽器的不兼容性,非常明確地定義了對前端工程師的需求。如今,前端專家是世界上最受追捧的候選人之一。

兩個 UI 層

即使在 Ajax 繁榮之後,前端工程師也被視為主要在瀏覽器窗口內處理技術。 HTML、CSS 和 JavaScript 是主要優先事項,我們只會觸及後端(Web 服務器)以確保它正確輸出前端。從某種意義上說,有兩個 UI 層:一個在瀏覽器本身中,另一個在為瀏覽器生成有效負載的服務器上。我們對後端 UI 層幾乎沒有控制權,並且經常受制於後端工程師關於如何組合框架的意見——這種世界觀很少考慮到前端的需求。

在這個 Web 應用架構中,瀏覽器上的 UI 層是前端工程師的唯一領域。後端 UI 層是前端和後端工程師會面的地方,而服務器架構的其餘部分則是應用程序的核心所在。在那裡您可以找到對應用程序至關重要的數據處理、緩存、身份驗證和所有其他功能。從某種意義上說,後端 UI 層(通常以模板的形式)是應用服務器內部的一個薄層,僅作為前端作為其正在執行的業務邏輯的附帶服務。

所以前端是瀏覽器,其他一切都是後端,儘管後端 UI 層有共同的會場。直到最近都是這樣。

輸入 Node.js

當 Node.js 首次發佈時,它在前端工程師中激起了一定程度的熱情,自從“Ajax”一詞首次出現以來,這種熱情就從未出現過。在服務器上編寫 JavaScript 的想法——我們只在被迫時才會去的地方——令人難以置信的自由。除了我們在前端所做的工作之外,我們不再被迫應付 PHP、Ruby、Java、Scala 或任何其他語言。如果服務器可以用 JavaScript 編寫,那麼我們完整的語言知識將僅限於 HTML、CSS 和 JavaScript 來交付完整的 Web 應用程序。這個承諾過去和現在都非常令人興奮。

我從來都不是 PHP 的粉絲,但我在 Yahoo 的工作中不得不使用它。我為我們調試的可怕時間和所有愚蠢的語言怪癖感到悲哀,這些怪癖讓你比應該做的更容易射中自己的腳。在服務器上使用了 6 年的 Java 之後,我發現切換到 PHP 很不爽。我相信並且仍然相信,靜態類型語言正是您在業務邏輯的核心中想要的。儘管我很喜歡 JavaScript,但也有一些我不想用 JavaScript 編寫的東西——例如我的購物車。

對我來說,Node.js 從來都不是用 JavaScript 替換服務器上的所有東西。你能做這樣的事情是驚人的和授權的,但這並不意味著它在任何情況下都是正確的選擇。不,對我來說,我有一個非常不同的用途:將後端 UI 層從後端的其餘部分中解放出來。

隨著許多公司轉向面向服務的架構和 RESTful 接口,現在將後端 UI 層拆分到自己的服務器中變得可行。如果應用程序的所有關鍵業務邏輯都封裝在 REST 調用中,那麼您真正需要的只是能夠進行 REST 調用來構建該應用程序。後端工程師是否關心用戶如何從一個頁面移動到另一個頁面?他們是否關心導航是使用 Ajax 還是使用全頁面刷新完成的?他們關心你使用的是 jQuery 還是 YUI?一般來說,一點也不。他們真正關心的是以安全、一致的方式存儲、檢索和操作數據。

這就是 Node.js 為前端工程師提供強大功能的地方。後端工程師可以用他們想要的任何語言編寫他們的 REST 服務。作為前端工程師,我們可以使用 Node.js 使用純 JavaScript 創建後端 UI 層。我們可以通過調用 REST 來獲得實際的功能。前端和後端現在在從事這些部件工作的工程師之間有著完美的分工。前端已經擴展回現在存在 Node.js UI 層的服務器上,堆棧的其餘部分仍然是後端工程師的領域。

不!可怕!

這種前端對傳統後端的侵占對於後端工程師來說是可怕的,他們中的許多人可能仍然對 JavaScript 作為一種“玩具”語言懷有怨恨。根據我的經驗,正是這一點導致了與採用(或不採用)Node.js 有關的組織分歧。後端 UI 層是前端和後端工程師之間的爭議之地。除了事情一直如此,我看不出發生這種情況的任何原因。一旦你進入服務器,這就是後端工程師的責任。這是一場簡單明了的地盤爭奪戰。

然而它不一定是那樣的。將後端 UI 層與後端業務邏輯分離在更大的 Web 架構中才有意義。為什麼前端工程師應該關心執行關鍵業務功能所需的服務器端語言?為什麼該決定會洩漏到後端 UI 層?前端的需求與後端的需求根本不同。如果你相信單一職責原則、關注點分離和模塊化等架構概念,那麼我們之前沒有這種分離似乎幾乎是愚蠢的

除了之前,Node.js 並不存在。前端工程師自己構建後端 UI 層並不是一個好的選擇。如果您使用 PHP 構建後端,那麼為什麼不使用 PHP 模板來構建您的 UI?如果您在後端使用 Java,那麼為什麼不使用 JSP?沒有更好的選擇,前端開發人員不情願地選擇了他們必須使用的任何東西,因為沒有真正的替代品。現在有了。

結論

我喜歡 Node.js,我喜歡它帶來的可能性。我絕對不相信整個後端都應該用 Node.js 編寫,因為它可以。然而,我堅信 Node.js 讓前端工程師能夠完全控制 UI 層(前端和後端),這使我們能夠更有效地完成工作。我們最了解如何輸出優質的前端體驗,而很少關心後端如何處理其數據。告訴我們如何獲取我們需要的數據以及如何告訴業務邏輯如何處理這些數據,我們就能夠製作出客戶喜愛的美觀、高性能、可訪問的界面。

使用 Node.js 作為後端 UI 層還可以讓後端工程師不必擔心一大堆他們不關心或既得利益的問題。我們可以找到 Web 應用程序開發的靈丹妙藥:前端和後端只在數據中相互通信,只要 RESTful 接口保持不變,就可以快速迭代而不影響對方。跳進去,水很好。


Tutorial JavaScript 教程
  1. 如何使用 jQuery 打開 Bootstrap 模式窗口?

  2. 哪個元素導致水平滾動條?自動檢測

  3. 如何僅從用戶的公鑰中獲取用戶的密鑰對(Solana)?

  4. 如何使用 React 和 MomentJS 創建倒計時組件

  5. 在 React 中構建下拉菜單的幾種方法

  6. JS中的迭代機制,也許是一個可能的錯誤?

  7. 故事書 6 的新內容

  1. React 和 D3:動態 COVID-19 可視化(第 2 部分:國家/地區比較儀表板)

  2. 加載元素後如何告訴 JavaScript 執行函數?

  3. REST API 設計的 8 個最佳實踐

  4. Object.entries 和 Object.keys 有什麼區別?

  5. 10 個實用的 JavaScript 技巧

  6. 用鼠標中鍵提交表單

  7. NLP.js 入門

  1. React-native 新架構,期待什麼?

  2. JavaScript Nullable – 如何在 JS 中檢查 Null

  3. 如何更改您的 WordPress 域(保持 SEO 優勢)

  4. 如何使用 Vue 3 設置 Tailwind