我們如何透過 Alchemy 的 Notify API 和 SDK 每年節省超過 300 萬美元

就在我們眼皮底下的重大優化

如果你在 web3 領域開發，就需要測試你的去中心化應用程式。但在正式網路上測試需要花費大量資金。因此 web3 開發者會使用 像 Goerli 這樣的測試網路，在上面交易與驗證行為都可以用測試網代幣免費進行。

要取得測試網代幣，你需要水龍頭（faucet）。水龍頭是一種關鍵服務，會把免費的測試網代幣「發放」給開發者，讓他們能在 Goerli 或 Mumbai 等測試網路上進行開發。

在 Alchemy，我們的使命是把 web3 帶給十億人，尤其是這些開發者。因此我們打造了水龍頭，讓開發者更容易進行開發，為所有開發者帶來前所未有的測試網代幣存取能力，同時簡化並推廣 web3 開發。

自 2021 年起，我們一直在營運 Goerli Faucet 與 Mumbai Faucet（還有已淘汰的 Rinkeby Faucet），已經向開發者發送測試網代幣超過 300 萬次！

Goerli 與 Mumbai faucet 目前承載的流量相當龐大，營運這些 faucet 每年要讓 Alchemy 花費數百萬美元。但我們最近發現了一個 300 倍的成本節省方案，總計每年省下超過 300 萬美元。

你一定好奇是怎麼辦到的？

答案是使用 Alchemy Notify 和 Alchemy SDK……我們自己的產品……就在我們眼皮底下。

往下讀 👇 了解我們如何優化 faucet。你也可以用我們的方法來優化自己的應用程式。

問題：過多（而且昂貴）的 JSON-RPC 呼叫

我們營運 faucet 方式的兩個主要問題是：

1. 過多的 getTransactionReceipt 呼叫
2. 使用了舊版的 web3 函式庫

考量到 faucet 每日請求量，發送到我們節點的 RPC 呼叫總數迅速累積。

讓我們深入分析每個問題。

1. 沒有通知系統來確認交易已上鏈

每次使用者請求 Goerli ETH（GETH）或 Mumbai MATIC 時，我們都會連續呼叫 getTransactionReceipt，直到交易確認上鏈為止，單一使用者請求往往需要呼叫多次 getTransactionReceipt。

在正常的 faucet 流量下，若不是因為舊版 web3 函式庫的錯誤，這種做法雖然相當不划算，但還不至於成本過高。

平均而言，每次使用者從 faucet 請求代幣時，我們都會呼叫約 16 次 getTransactionReceipt。

2. 使用舊版 Web3 函式庫

我們的服務使用了一個舊版的 web3 函式庫，而我們當時並不知道其中有個錯誤。即使在交易確認成功之後，系統仍會持續呼叫我們的節點，大幅增加（不必要的）呼叫 getTransactionReceipt 的總次數。

Free video demo

實際操作 Alchemy 儀表板

30 分鐘導覽：現場示範儀表板中的每項工具。

Watch the demo

解決方案：Alchemy Notify 與 Alchemy SDK

我們實施的兩個主要解決方案，用來減少對節點的昂貴 JSON-RPC 呼叫，分別是：

1. 將 getTransactionReceipt 呼叫替換為 Alchemy Notify 的 webhook 通知
2. 將舊版 web3 函式庫替換為 Alchemy SDK

1. 遷移到 Alchemy Notify

我們已經放棄直接呼叫原始的 getTransactionReceipt 方法，改用 Alchemy Notify 的 webhook 來在交易上鏈或被丟棄時即時取得通知。在完全沒有對外呼叫的情況下，當使用者成功收到 GETH 時，通知會直接傳送給我們。

2. 升級到 Alchemy SDK

我們從舊版 web3 函式庫遷移到 Alchemy SDK，有效修復了那個導致所需 getTransactionReceipt 呼叫數量呈指數成長的錯誤。

年度成本節省

這兩項簡單的改動，為我們團隊省下了超過 300 萬美元的年度成本。營運我們的 faucet，年度總成本降至大約 560 美元。🤯

這對你的專案意味著什麼

像 Alchemy Notify 與 Alchemy SDK 這樣的產品，就是為了解決那些讓你的 web3 產品變得不必要地昂貴、繁瑣又耗時的問題而設計的。

它們都非常容易設置，而且省下的成本與時間，能確保你有足夠的時間與資金專注在前端核心業務上，而不必再為後端基礎設施煩惱。