第 176 期 Backend 推薦文章

# Backend & Data Engineering

# [中] Backend for Front-End (BFF)

在過去,應用程式相對簡單,瀏覽器向網路應用程式端點發送請求,後者從資料庫中擷取資料並回傳響應。然而,隨著移動客戶端與其他應用程式整合,這種簡單性被打破。本文介紹了一種處理這種複雜性的解決方案。

傳統方法中,應用程式返回所有資料,然後由各個客戶端過濾不需要的部分。然而,移動客戶端的頻寬有限,且不是所有手機都支援高速網路。因此,這種過度提取的方法不可行。

面對這個問題,提出了面向前端的後端(BFF)的解決方案。BFF 將每個微服務中的邏輯移至一個專用的部署端點。這個端點負責從所需的微服務中擷取資料,過濾相關部分,將它們聚合並以符合特定客戶端需求的格式回傳。

BFF 的概念是由負責前端的團隊開發和管理,這樣可以在提高開發速度的同時,提供與微服務相同的彈性。BFF 可以被視為獨立部署單元或 API 網關的一部分,取決於組織的需求。

在性能方面,與巨石應用程式相比,使用 BFF 會增加額外的請求時間,但這些請求可以並行處理,因此對使用者體驗的影響相對較小。

然而,每個組織都有不同的需求和情況,實施 BFF 之前應該仔細考慮系統架構、團隊組織和性能目標。

# [中] 資料工程師看台灣職場觀察與回顧:Data Engineering 是個有挑戰&變化的領域

這篇文章是一位台灣資料工程師經歷的精彩冒險!作者畢業於國立大學資工系,對人工智慧充滿興趣。儘管在畢業專題時自學了類神經網路,卻被評為效果平平。然而,一年後回到現實世界,作者驚訝地發現最新潮的 Deep Learning 原來就是類神經網路的延伸應用!這讓他對資料和機器學習領域充滿了熱情。

大學時期,作者曾在朋友的幫助下接案開發網站,但工作一年後,他感到了一絲索然無味。於是,他開始追逐自己對資料和機器學習領域的熱愛,經過一段時間的自學後,他慶幸地得到了布丁大大的賞識,並成功轉職為一名資料工程師!從此展開了他精彩刺激的職業生涯。

資料工程師這個新興領域的範圍非常廣泛,從基礎服務到資料處理應用,甚至連分析和視覺化也可能涉及其中。每家公司對於資料工程師的需求都各不相同,有些想要一個能點石成金的魔法石,有些需要一個能治百病的仙丹,還有些只是需要一個能大肆宣傳的廣告看板。

相較於後端工程師,資料工程師更像是一位水管工,主要負責串接和維護資料管線。然而,資料工程師的工作並不像後端工程師那樣龐大,而是由許多小元件組成一個完整的架構。不同的資料類型和後續應用對整體架構都有很大的影響,因此沒有一個簡單的最佳實踐方法。不過,近年來各大雲服務提供商提供了越來越完整的相關服務,為起步選擇提供了不錯的選項。

作者提到,成為一名優秀的資料工程師需要不斷學習和探索,保持對新技術的敏感度。除了技術上的挑戰外,溝通和合作也是非常重要的,因為資料工程師往往需要與不同團隊合作,並將資料轉化為有價值的洞察。

這位資料工程師的職業生涯展示了一個從追求熱愛到實現夢想的故事,並且強調了資料工程師的重要性和多樣性。無論是對資料和機器學習充滿興趣,還是尋求一個充滿挑戰和成就感的職業,資料工程師都是一個令人嚮往的選擇!

# [中] 把 RabbitMQ 換成 PostgreSQL 的那篇文章

這篇摘要的文章是從 Hacker News 引用的,原文標題為「SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue」,作者在文章中討論了將 RabbitMQ 替換為 PostgreSQL 的原因和結果。

文章中指出了一些值得吐槽的點,並且這些點在 Hacker News 上也被提到。其中有人指出他們遇到了一個錯誤(或特性),但沒有解決該錯誤,而是選擇直接改寫程式碼,將其改為使用 PostgreSQL 解決,這種做法很奇怪。另一個吐槽的點是關於量的部分,如果處理的量不大,降低技術堆疊使用 PostgreSQL 可能是一個不錯的決定。然而,有人質疑為什麼一開始要使用 RabbitMQ。同一個討論串中也有人提到處理的量實在太小,甚至開玩笑地說可以使用 Jenkins 來處理。

此外,一位名叫 Simon Willison 的人提到了 RabbitMQ 到目前為止仍然不支援 ACID 等級的工作排程,特別是耐久性的部分。他認為使用 PostgreSQL 作為佇列的好處是可以利用事務,只有在相關資料已經完全寫入資料庫且不可能發生佇列記錄未寫入的情況下才將工作放入佇列。同時他還推薦使用資料庫中的交易性「暫存」佇列,然後由另一個獨立的過程將其寫入實際佇列。

總結來說,原文中的公司在遇到 RabbitMQ 消費者程式庫和設定的問題時,決定換成 PostgreSQL,而不是解決問題。這引起了一些討論,並且有人對這種做法表示懷疑。同時,原文還提到了使用 PostgreSQL 作為佇列後端的優勢,特別是能夠利用事務來確保資料的完整性。然而,人們也提出了一些關於處理量和選擇技術堆疊的問題。

Tag

Recommendation

  1. 第 173 期 TypeScript 推薦文章
  2. 第 157 期 Golang 推薦文章
  3. 第 152 期 前端開發 推薦文章
  4. 第 151 期 前端開發 推薦文章
  5. 第 148 期 軟體工程 推薦文章

Discussion(login required)