大多數人過早地考慮了他們的後端。您開始建立新產品，突然開始研究 Kafka、Redis、後台工作程式、訊息佇列、分析管道、快取層和五種微服務。但如果你誠實的話，你可能並不需要其中的大部分。
對於大量的 SaaS 產品，尤其是早期產品，一個簡單的堆疊將使您走得更遠、更快。我的整個後端堆疊只是 TypeScript 和 Postgres——這已經足夠了。
以下是我在這個堆疊上建立UserJot 的方法以及我堅持使用它的原因。
TypeScript：一種統治堆疊的語言
隨處使用 TypeScript 意味著更少的上下文切換。我不需要在使用 Python（用於一個服務）、Go（用於另一個服務）和 JavaScript（用於前端）之間來回切換。一種語言可以處理一切——從編寫 API 邏輯到驗證資料，再到在整個應用程式中塑造類型。
在後端，TypeScript 出奇地好。使用tRPC和Zod等工具，您可以建立快速、完全類型安全的 API，甚至無需編寫單獨的模式或 REST 契約。您只需驗證一次輸入，即可在整個應用程式中推斷您的類型，並保持所有內容同步。
吸納新貢獻者也變得更容易。如果他們已經了解前端 TypeScript，他們很快就會掌握後端。您不需要教他們三種不同語言或框架的來龍去脈。
Postgres：一個功能強大的資料庫
人們喜歡使他們的資料堆疊複雜化。但說實話，Postgres 是個野獸。它像冠軍一樣存儲關係資料，如果您需要一些靈活性，它可以處理 JSON，支援全文搜尋，並且對索引和約束有出色的支援。
需要後台工作嗎？您可以使用LISTEN/NOTIFY 、計劃觸發器，甚至可以在單獨的工作進程中輪詢表。想要儲存應用程式事件、稽核日誌或分析？ Postgres 也可以做到這一點。
現代硬體使其更加強大。現今雲端基礎架構上的單一垂直擴充的 Postgres 執行個體可以擁有 64+ vCPU 和 256+ GB 的 RAM。對於大多數 SaaS 產品來說，這已經足夠了。實際上，99% 的應用程式永遠不會接近飽和狀態。
關鍵在於：每月活躍用戶不是並髮用戶。如果您有 100,000 個 MAU，這並不意味著您可以同時處理 100,000 個請求。大多數用戶每天登入的時間只有幾分鐘，有些甚至更少。您的並發量只是 MAU 的一小部分。您需要數百萬活躍用戶才能開始突破優化良好的 Postgres 實例的極限。
如果你達到了這一點，那將是一個很大的問題——而且你將擁有資源和時間來妥善解決它。過早的擴展不僅是不必要的，而且通常會導致更糟糕的決策和更脆弱的系統。
更少的活動部件 = 更專注
您帶來的工具越少，需要維護的東西就越少。每項新服務都會增加表面區域：設定檔、部署、邊緣情況、監控、故障復原。如果發生故障，您想知道去哪裡找。當你的堆疊只有兩樣東西時，除錯起來就會容易得多。
這也意味著您的本機開發環境很簡單。您不需要 Docker Compose 來運作 12 個容器。您不需要為後台作業、快取或服務間通訊提供單獨的服務。只需啟動您的 Node 伺服器和 Postgres 容器即可開始使用。
我之前已經建置過複雜的系統－Kafka 叢集、ClickHouse 分析管線、Redis 支援的作業佇列。他們都有自己的位置。但它們也有成本。而在產品早期，它們幾乎總是不必要的。
簡單的軟體具有更好的擴充性
這有悖常理，但堆疊越簡單，在實際需要時就越容易擴展。大多數人認為他們需要儘早進行優化，以便以後不會達到擴展極限 - 但事實通常相反。過早的優化會使您陷入難以撤銷的決策。它會產生複雜性，減慢您的速度，並使擴展變得更加困難，而不是更容易。
擴展基於 Postgres 和 TypeScript 建置的簡單應用程式比嘗試擴展「以防萬一」而加入的弗蘭肯斯坦怪物服務要容易得多。為成長做好準備的最佳方法是保持事物清潔，直到您知道真正需要擴展什麼。
你不是谷歌。擴展還不是你的問題（至少目前是如此）
大多數應用程式不需要擴充。他們需要生存足夠長的時間來獲得用戶。你很容易說服自己是為了擴大規模而進行建設，但你經常做的是浪費時間解決你沒有的問題。
Postgres 每秒可以處理數千次寫入。它可以輕鬆儲存數百萬行資料。垂直擴展可以讓你獲得意想不到的進步——一個強大的 Postgres 盒子將滿足你早期的擴展需求。一旦遇到真正的瓶頸，您就會確切地知道需要改進什麼。
過早優化是一種拖延行為。您可以發布功能，也可以花兩週時間為無人存取的主頁編寫完美的 Redis 快取層。我兩件事都做過。第一個獲勝。
專注 = 速度 = 更好的產品
簡單堆疊的最大優點是它可以讓您快速移動。您不需要花時間將服務黏合在一起或閱讀 20 頁您幾乎不了解的工具的文件。你只需建造。
CI/CD 變得更容易。測試變得更快。您需要保持更新的庫較少。當生產過程中出現故障時，需要尋找的地方就更少了。所有這些加起來意味著您需要花費更多時間來實際改進產品。
對於獨立開發者或小團隊來說，這是一個大問題。您可以用更少的程式碼、更少的錯誤和更少的上下文切換來完成更多的事情。您不會浪費精力去管理複雜性——您正在建立用戶真正關心的功能。
但後台任務、快取等等又如何呢？
總是會有一些極端情況需要你使用更複雜的工具。但即便如此，TypeScript 和 Postgres 通常也能讓你走得更遠。
後台工作？設定一個 cron 工作程序來檢查表中的作業並將其標記為完成。需要對事件做出反應嗎？在後端使用LISTEN/NOTIFY和輕量級事件調度程式。
快取?當然，您始終可以為特定端點分層簡單的記憶體緩存，甚至只使用 HTTP 層級的快取。對於大多數 SaaS 應用來說，這就足夠了。
分析？將事件記錄到 Postgres 表中，按計劃匯總它們，然後將它們顯示在儀表板中。除非您要推送大量即時資料，否則這已經足夠了。
事實是，您以後總是可以加入更多內容 - 但是一旦它們融入到您的架構中，就很難將其刪除。
最後的想法
我基於這個確切的堆疊建立了UserJot （一個使用者回饋工具）：僅使用 TypeScript 和 Postgres。它處理註冊、反饋提交、全文搜尋、API 請求、cron 作業、後台工作者、速率限制等——所有這些都無需引入任何其他服務。
如果您正在建立 SaaS 或內部工具，請不要想太多。堆疊不必太華麗。它只是需要可靠且快速地建造。 TypeScript 和 Postgres 將帶你走得比大多數人想像的更遠。
保持簡單。動作要快一點。當最終需要擴展時，您會很高興從乾淨的東西開始。
我偶爾會發送這樣的貼文——加入清單吧。
原文出處：https://dev.to/shayy/my-backend-stack-is-just-typescript-postgres-heres-why-thats-enough-1pni
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式