作為一個開發者,你可能已經利用過REST API來構建和整合各種應用。REST API是基於HTTP協定的互動模式,它使得使用者端和伺服器可以通過請求和響應來進行資料交換,簡單、靈活、通用。
然而,當你開發實時應用,如IM聊天、共同作業等應用時,意味著使用者端需要不斷向伺服器請求才能獲取到最新資料,這將浪費大量網路流量和資源,導致資料延遲。要麼採用複雜的WebSocket協定,但無疑會增加開發的難度和成本。為此,我們是否能找一種更簡便、低成本的解決方案呢?答案是肯定的,它就是Pushpin。
Pushpin是用Rust和C++編寫的反向代理伺服器。它可以讓你在不修改後端程式碼的情況下,為你的REST API新增實時通訊功能。它支援WebSocket、HTTP流和HTTP長輪詢等多種實時協定,讓你的前端和後端之間實現雙向通訊。
Pushpin不會快取資料,不會影響應用程式的資料模型,也不會繫結您的 API 定義。它只是一箇中間層,讓後端能夠根據自己的資料模型來處理使用者端的請求。使用者端也不必關心「頻道」或「訊息」的概念,只要傳送 HTTP 請求或 WebSocket 幀,後端就能根據這些輸入來推播實時資料。
Pushpin它作為一箇中間層,接收前端發來的請求,並轉發給後端。如果後端返回了一個普通的HTTP響應,Pushpin就直接返回給前端。如果後端返回了一個特殊的響應,比如帶有Grip頭部或者帶有訂閱資訊,Pushpin就會保持連線,並等待後端通過控制API推播資料給前端。
這樣一來,你就可以在後端使用任何語言和框架來開發REST API,而不需要關心實時協定的細節,只要你按照Pushpin提供的規範來返回響應和推播資料,Pushpin就會自動為你處理好前端和後端之間的實時通訊。
Pushpin非常適合各種設定,因為它充當代理伺服器和釋出-訂閱代理。
1、代理
最基本的設定是將Pushpin放在典型的Web服務後端前面,後端將資料直接釋出到Pushpin。Web服務本身可能會發布資料以響應傳入的請求,或者可能存在某種釋出資料的後臺程序/作業。
2、 使用API管理
可以將API管理系統與Pushpin結合使用。將Pushpin放在前面,以便API管理系統不會受到長期連線的影響。此外,Pushpin可以將WebSocket協定轉換為HTTP,允許API管理系統對轉換後的資料進行操作。
3、 使用訊息佇列
如果要推播大量資料,則可能需要引入中間訊息佇列。這樣,後端程序可以將資料一次性發布到訊息佇列,佇列再通過介面卡將資料中繼到一個或多個Pushpin範例。Pushpin能夠將訂閱資訊轉發到此類介面卡,以便訊息能傳送到具有給定通道訂閱者的Pushpin範例。
在微服務環境中,Pushpin可以輕鬆偵聽來自其他微服務的即時更新,而無需集中式訊息代理。每個微服務都有自己的Pushpin範例,微服務通過組織自己的API協定而不是特定於供應商的機制相互通訊。5、 作為大型 CDN
由於Pushpin範例互不通訊,並且訊息傳遞可以分層,這意味著Pushpin範例可以在地理上分佈以建立實時推播 CDN。使用者端可以連線到最近的區域邊緣伺服器,事件可以從資料來源輻射到邊緣。
為了方便整合,提供有許多後端語言和框架的庫:
Pushpin在Apache許可證 2.0 版下獲得許可,它是一個讓你的REST API變成實時API的神器,它可以為你的應用新增實時通訊功能,無縫地與現有的REST API整合。它支援多種實時協定,可以和任何語言和框架配合使用,還提供了高效穩定的服務。如果你想要開發一個實時的應用,不妨試試Pushpin!
專案地址:https://pushpin.org/ 檔案地址:https://pushpin.org/docs/about/ 原始碼地址:https://github.com/fastly/pushpin
寫作不易,轉載請註明博文地址,否則禁轉!!!