在過去的 4-5 年裡，我嘗試了大量的 Solana 應用架構，現在是時候把我的發現寫下來了。從最簡單的開始，逐漸增加複雜性。那麼，開始吧：Solana 應用架構，一個主題。

2) 讓我們從簡單模式開始。這可能是你第一個 Solana 應用的樣子。一個簡單的 React 前端，建立與 RPC 的連接。沒有必要有 API 伺服器。RPC 就是你的伺服器。在早期，這些充斥著 getAccountInfos、定制的交易構建邏輯等。 後來，當性能受到影響時，你會添加緩存和批處理的層次。進入 getMultipleAccounts。也許你還會添加 websocket 訂閱 + 輪詢來實時更新 UI。 這種架構使得原型設計極其快速。幾乎沒有 DevOps。伺服器成本微乎其微（只需在 vercel 上部署等）。不過，它有幾個主要缺陷。

3) 你遇到的第一個問題是複雜查詢。在這種架構中，你所擁有的只是普通的 Solana RPC。這意味著你需要將 Solana 當作 RPC 所暴露的方式來處理——就像是一個有態度問題的 NoSQL 數據庫。點查詢沒有問題。你甚至可以利用 PDA 來像圖形數據庫一樣遍歷你的程序數據，發揮創意。 但一旦你需要進行第一次 gPA，你就會面臨極大的痛苦。這個介面根本不符合人體工學。如果你有任何動態長度的數據，它根本無法使用。根據你的 RPC 提供者，速度可能會慢得令人難以置信。 即使沒有 gPA，這種方法通常也比典型的 web2 應用程序（具有伺服器端渲染和正常數據庫）慢得多。

4) 你遇到的第二個問題是交易構建邏輯的可攜性。使用這種設置，所有構建交易的邏輯要麼 (a) 在你的前端代碼中，要麼 (b) 在你的代碼導入的庫中。在 (a) 的情況下，任何想要在你的前端之外構建交易的人都會面臨極大的困難（這包括你，當你不可避免地需要更多的應用時）。在 (b) 的情況下，對交易構建邏輯的任何更改都需要庫的發布，每個人更新他們的包，然後進行 UI 更新。 大量依賴像帳戶解析這樣的 Anchor 工具可以最小化需要移植的邏輯量——但問題依然存在。這剝奪了你的靈活性，並使得在確保所有版本的 TX 構建邏輯繼續運行的同時，難以更改智能合約端點。

5) 第三個問題是，使用者介面通常在提交交易時表現不佳，特別是在重試邏輯方面。使用者可能會離開頁面，交易停止重試。大量交易往往難以成功。從遠處很難調試為什麼交易無法成功。

6) 這裡的最後一個問題是，你並不是唯一擁有這種架構的人。RPC 是有價值的，你基本上必須在前端暴露你的 RPC URL。現在，你將陷入一場貓捉老鼠的遊戲，以確保沒有人竊取你的 RPC 並提高你的成本。

7) 那麼接下來是什麼？通常即使你沒有解決交易可攜性，你最終也需要解決列表查詢。gPA 很糟糕，我們都知道這一點。因此，你可以構建一個混合架構。 在這個架構中，你保留快速原型設計的能力，但將那些難以處理的查詢推送到 API。這方面的一個具體例子是治理——你有提案被創建，並且有一組標籤（"經濟"、"技術"等）。gPA 無法按標籤過濾。

8) 這種架構並未解決交易的可攜性，或是人們拔掉你的 RPC。但在規模上，你至少可以解決慢/無法進行 gPA 的問題。 它確實引入了一個新問題——索引器。稍後會詳細說明。

9) 最後，你擁有我所稱的「企業」Solana 堆疊。你不再將 Solana 當作 NoSQL 數據庫來處理。相反地，你將它視為事件總線。前端對 Solana 的數據模型一無所知。伺服器構建交易並將其傳遞給 UI 進行簽名，然後將其發送到 Solana 本身。它將這視為一個事件，並等待它傳播回索引器，這將改變底層數據。 這種設置具有很好的交易可攜性 - 任何人都可以用乾淨的參數訪問你的 API，並獲得交易/指令的回應。 這使得 UI 極其靈敏 - 就 UI 而言，這基本上是 web2。你可以充分利用 SSR。 RPC 被抽象化 - 沒有人可以竊取你的信用。 但這種設置也有其問題。

10) 你會遇到的第一個問題是索引器的痛苦。雖然在過去幾年中這個問題有所緩解（多虧了Triton、Helius和StreamingFast團隊），但我仍然經常用扳手打我們的索引器。你會錯過消息。當你錯過一條消息時，你的用戶界面會進入一種奇怪的狀態（例如：我給你發了一個NFT，鏈上你收到了，但我的數據庫卻顯示我仍然擁有它）。這類問題讓人感到無比沮喪。是你的錯嗎？還是你的數據提供者的錯？誰知道呢！你的下午就這樣過去了。

11) 接下來你會遇到的問題是時機。當你直接使用 RPC 來處理所有事情時，他們允許你傳遞承諾並處理最新數據。使用索引器時，這一切都是手動的。這意味著當你構建交易時，你可能是基於過時的數據來構建它們。你返回的交易注定會失敗。 你可以通過使用提供極快數據的數據提供者來解決過時數據的問題（例如 Helius 激光流）。但這樣你需要手動處理重組。也就是說，如果該交易實際上沒有通過，那麼你索引的數據需要被取消索引。這真是一場噩夢。

12) 你可以通過僅使用來自 RPC 的數據構建交易來 "破解" 時間問題，並僅使用你的索引數據來供應 UI。但這樣，使用者仍然會面臨 UI 和鏈之間潛在不一致的問題。也就是說，前端說我擁有這個 NFT 並可以轉移它，然後後端卻對我大喊說我不能。

13) 你在這個設置中遇到的最終問題是成本，如果我們要戲劇化地說，就是「去中心化的死亡」。web3 的夢想是無需部署大量的集中式伺服器。現在你已經部署了足夠的基礎設施，讓你能在 web2 公司獲得首席架構師的職位。這需要花費金錢，花費時間。而且這一切都是非常集中化的。如果與你的協議互動的最佳方式是通過 web2 API，那麼你的協議有多去中心化？而且在 solana 上有大約 72 位開發者知道如何在沒有該 API 的情況下與之互動。

14) 最終，我不會在去中心化的問題上堅持不懈。對用戶來說最好的選擇往往是最佳選擇。"企業"設置導致快速、現代的網頁應用程序和清晰的關注點分離。缺點是，它增加了運維成本，並使你變得不那麼靈活。我建議大多數初創公司使用直接到rpc的方法，除非你正在構建一些明確需要快速或具有複雜查詢語義的東西。市場時間是關鍵。你總是可以稍後雇用一名中級工程師，並把他們扔進索引地牢。

15) 財務。如果你們中有誰找到更好的設置，請告訴我。這些都是我嘗試過的東西。最近我很享受玩弄企業設置。