技術文章 » 探索Node中如何應用反應式程式設計？優缺點分析

探索Node中如何應用反應式程式設計？優缺點分析

2022-02-14 22:00:30
本篇文章帶大家用Node.js探索一下反應式程式設計，介紹一下在中應用反應式程式設計的方法，以及它的好處和利弊，希望對大家有所幫助！

反應式程式設計提供了先進的資料流，能夠以一種可預測的方式建立和操作事件流。

本文將告訴開發者如何在Node中應用反應式程式設計，以及它的好處和利弊。

本文將涉及以下內容。

  • 反應式程式設計的基本原理

  • 為什麼考慮在Node.js中進行反應式程式設計？

  • 何時使用反應式程式設計方法

  • 反應式程式設計的好處

  • 反應式程式設計的弊端

  • 介紹協調和它的好處/利弊

  • Node的反應式程式設計庫

什麼是反應式程式設計？

簡而言之，當輸入的變化導致輸出的相應變化，而不需要手動更新輸出的變化時，就可以說一個程式是反應式的。這使得軟體工程師可以繞過手動處理巨大實現的壓力。

功能性的反應式程式設計正規化使我們的反應式程式碼庫很容易被閱讀和理解，因為它減少了回撥地獄，這使得非同步的程式碼塊難以閱讀。

由於反應式程式設計與非同步操作有很大關係，函數式方法使我們更容易確定非同步操作的結果。

反應式程式設計的基本原理

操作符

操作符是Observables嚴重依賴的方法。它們有以下使用情況。

  • 在處理非同步請求時，將非同步事件轉換為Observables
  • 將多個可觀察變數的序列組合成一個單一的可觀察變數
  • 錯誤處理
  • 處理基於時間的操作

可觀察操作符包括[filter(...)](https://rxjs.dev/api/operators/filter),[mergeMap(...)](https://rxjs.dev/api/operators/mergeMap),[of](https://rxjs.dev/api/index/function/of),[from](https://rxjs.dev/api/index/function/from),[concat](https://rxjs.dev/api/index/function/concat) 方法，等等。

可觀察流

一個Observable流是一個由多個輸入值組成的陣列，它隨著時間的推移被處理。一個Observable流向它的訂閱者發出事件，而訂閱者又聽從這些事件進行進一步處理。可觀察的流可以被組合來建立新的流。陣列方法，如map,reduce,filter ，等等，都是用來操作流的。

值可以按以下方式發射給訂閱者。

import { of, Observable } from "rxjs"; 
const emitter : Observable<string> = of("Sam", "Ray", "Thomas");

訂閱者

Observable訂閱器更像是陣列迭代器。它們在產生的Observable流中迴圈，使之有可能轉換或處理每個流。

下面的片段展示瞭如何訂閱一個Observable流。

emitter.subscribe((value: string) => {
  console.log(`Name: ${value}`)
})

反應式程式設計有一些內建的訂閱方法，如emit 和flatMap map方法，這些方法允許我們監聽Observable流的每個值，並根據我們的需要對它們進行處理。

反應式系統的標準

一個完全反應式的Node.js系統應該滿足以下標準。

響應式架構

一個反應式系統應該擁有良好的使用者體驗，對使用者的互動提供及時的響應。

彈性架構

彈性架構，如果正確實施，將允許系統響應錯誤而不破壞整個系統。

這種架構確保每個節點都有一個複製品。如果主節點發生故障，在其他可用的節點上會有某種回退。

可延伸性

系統應該能夠處理不同的負載，這與它的能力有關，當基礎設施需要很少或沒有資源時，它可以縮小規模，而當基礎設施需要更多資源時，它可以擴大規模，以便提供一個有效的成本管理策略。

此外，該系統也應該能夠處理時間點的負載。

為什麼要考慮Node.js的反應式程式設計？

現在我們已經簡要地討論了反應式程式設計的基本原理，瞭解考慮用Node.js進行程式設計的反應式方法的原因也很重要。

可延伸性

編寫功能性的反應式程式碼可以更容易地管理程式碼庫，提高專案的可延伸性。

功能實現

對於需要定期修改功能或增加新功能的專案來說，編寫功能性反應式程式碼使得新功能更容易被新增到現有專案中。

與時間相關的錯綜複雜的問題

在對外部API進行非同步請求時，我們確實會遇到一些時間限制的約束。這些限制可以用反應式程式設計方法有效地處理。

減少程式碼的冗長性

實施反應式程式設計正規化將極大地減少實現特定功能所需的程式碼量。

引入協調和它的好處/權衡

在反應式程式設計誕生之前，用Node.js構建微服務需要協調所有服務互動的協調器模式。

協調器模式的一個典型用例是在電子商務應用中擁有微服務，這些微服務按順序處理以下任務：從購物車中獲取客戶訂單，計算總金額，生成賬單，在成功付款後，更新產品庫存並建立一個訂單ID，並向賣家提供Pending 。

雖然這提供了一個系統的方法來處理應用程式的邏輯流程，但依賴關係緊密耦合的一個主要缺點會破壞整個系統。例如，如果前面的服務出現故障，那麼所有的依賴服務都不會被執行。

在Node.js中何時使用反應式程式設計方法

反應式程式設計不是一個萬能的方法，但它在一些特定的情況下是非常合適的。

  • 當需要將應用流分散到可管理的微服務中時，反應式程式設計模式是非常合適的。
  • 當需要在有限的時間內將應用交付給生產時
  • 當前面的一個依賴性的臨時關閉會導致整個系統的崩潰時
  • 當有很多非同步的程式碼塊，而等待的結果可能被延遲時，反應式程式設計也是非常合適的。

Node.js中的反應式程式設計的弊端

雖然功能化的反應式程式設計方法減少了協調器模式遇到的缺點，但它不能取代協調器模式，因為它有自己的缺點。

  • 分解應用流程並分佈在所有服務中所產生的冗餘程式碼塊
  • 為了構建反應式服務，需要對流和事件迴圈有一個全面的瞭解

Node.js中流行的反應式程式設計庫

RxJS

這是JavaScript中最流行的反應式程式設計庫之一，被積極維護。

在寫這篇文章的時候，RxJS正在從v7過渡到v8，它在上週有超過2700萬次的下載。這次過渡的特點是重寫了庫的效能，更好的模組化，更好的可偵錯的呼叫堆疊，以及向後的相容性。

下面是一個快速的RxJS使用例子。

import { range } from "rxjs";
import { map, filter } from "rxjs/operators";

range(1, 200)
  .pipe(
    filter(result => result % 2 === 1),
    map(result => result * 2 )
  )
  .subscribe(result => console.log(result));

Reactor.js

Reactor.js是另一個用於反應式程式設計的JavaScript庫。雖然與Bacon.js和Rxjs相比，它還不是很流行，但它以輕量而聞名。使用Reactor.js在複雜的資料模型中保持一致性要容易得多，因為它能自動跟蹤反應式變數，並在任何反應式變數的值發生變化時重新觸發觀察者。
使用Reactor.js，不需要手動設定訂閱/監聽器，因為依賴關係會自動為你設定。

下面是一個Reactor.js使用的快速例子。

const reactor = new Reactor({ name: "Doe" });

observe(() => {
  console.log("My name is ", reactor.name);
}); // prints "My name is Doe"

reactor.name = "John "; // prints "My name is John"

Reactor是基於與Bacon.js和Knockout.js相同的反應式原理。

其他用於反應式程式設計的JavaScript庫包括。

  • Flyd
  • Bacon.js
  • Knockout.js
  • Kefir
  • 大多數

總結

在這篇文章中，我們探討了反應式程式設計，它的好處，以及何時最適合我們的Node.js專案。此外，我們還討論了協調、其好處/利弊以及用於Node.js中反應式程式設計的JavaScript庫。

希望你能發現這篇文章的資訊量和幫助。

更多node相關知識，請存取：！

以上就是探索Node中如何應用反應式程式設計？優缺點分析的詳細內容，更多請關注TW511.COM其它相關文章！