第 176 期 - Bug 最近會不會也開始因為業力引爆？

Created on 2023-06-13

本週專欄

什麼?!元件竟然也有分可控制與不可控制 - 探討 React Controlled 以及 Uncontrolled Component

在 React.js 的世界中有分成 Controlled 以及 Uncontrolled 兩種 Component，Andy 本篇文章除了介紹這兩種 Component 外也會介紹一些常用的 form 套件是如何控制其底下的 component，對於想要更深入了解 React.js 的朋友可以參考看看～

Golang

SOLID Principles with Go Examples Every Developer Should Master

大家應該都聽過 SOLID 中的五個原則，他們目的就是為了讓你的程式碼更好維護。但知道歸知道，能不能實際運用又是另外一回事，所以這篇文章就用了超多例子來講解怎麼在 Go 中符合 SOLID 的程式碼。雖然 Go 不是一個典型 OOP 的語言也沒有所謂繼承，但用 interface 還有 composition 還是一樣可以寫出很漂亮的程式碼！

ChatGPT, Wardley and Go

自從 ChatGPT 開放 plugin 功能之後，各種 plugin 就如雨後春筍般一直冒出來，而這篇文章正是教你怎麼用 Go 寫一個自己的 plugin。看完這篇文章後，你就能知道 ChatGPT 跟 plugin 的溝通流程，還有怎麼在 ChatGPT 上面畫圖XD，是非常有趣的一篇文章～

Finding The Best Go Project Structure

關於怎麼規劃專案的目錄結構，一直以來都是個沒有標準答案的問題，而這個系列文嘗試比較了各種目錄結構的優缺點，如果你最近有打算開一個新專案的話，可以先參考看看這個系列文，讓你的程式碼更好管理。

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 作為佇列後端的優勢，特別是能夠利用事務來確保資料的完整性。然而，人們也提出了一些關於處理量和選擇技術堆疊的問題。

Writer:

@AndyChen - 嗨嗨我是Andy，用嘴巴工作的工程師😂，喜歡學習不同領域的內容，專長為網頁開發，歡迎大家跟我聊技術～

Maintainers:

@LarryLu - 我是 Larry，傳說中的 0.1 倍工程師！
@GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
@LukaTW - 一名全身都是死角的工程師。
@smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術。
@RicoChen - 熱愛許多技術且努力看透技術的本質，如果有什麼好玩的技術，還請各位歡迎直接找我聊聊。

Feedback

本週呈現主題方式做了一些改變，希望讓讀者能夠更快速精準的找到自己要的資訊。也加入社群活動這個區塊，每週更新社群活動的資訊。如果有任何建議，歡迎私訊星巴哥技術週刊 FB 粉絲專頁與我們聯繫。