CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章 👉 上自學課程 👉 討論區交流

🔍 搜尋結果：posthog

我們在使用 Rust 建構 SaaS 時學到了什麼

在這篇文章中，我們**不會**回答每個人在開始新專案時都會問的問題：**我應該用 Rust 來做嗎？** ![](https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExNHQwOTl6Ym5odmVmNDZpdzVmZG9mMW9yd2tmN2lyZ2NzOWNxc2MxMCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/l83rkRUu4IqyUbt5k6/giphy.gif) 相反，我們將探索在自信地回答「**絕對！** 」並開始主要使用 Rust 建立業務後遇到的陷阱和見解。這篇文章旨在提供我們經驗的高層次概述，我們將在即將推出的系列中更深入地研究細節。（在評論中為我們的下一篇文章投票🗳️） --- 為什麼生鏽 ----- 為專案選擇正確的語言從來不是一個一刀切的決定。關於我們的團隊和用例的幾句話： - 我們是一個 6 人團隊，幾乎沒有 Rust 經驗，但擁有建立資料密集型應用程式的豐富 Scala/Java 背景 - 我們的 SaaS 是一個計費平台，專注於分析、即時資料和可操作的見解（想想 Stripe Billing 與 Profitwell 的結合，再加上一點 Posthog）。 - 我們的後端完全採用 Rust（分為 2 個模組和幾個工作線程），並使用 gRPC-web 與我們的 React 前端進行對話 > 我們是開源的！ > 您可以在這裡找到我們的儲存庫：https://github.com/meteroid-oss/meteroid > 我們期待您的支持 ⭐ 和貢獻因此，我們有一些不可協商的要求恰好非常適合 Rust：**效能、安全性和並發性**。 Rust 實際上消除了與記憶體管理相關的所有 bug 和 CVE，而它的並發原語非常有吸引力（並且沒有讓人失望）。在 SaaS 中，所有這些功能在處理敏感或關鍵任務時尤其有價值，例如我們案例中的計量、發票計算和交付。正如[包括微軟在內的](https://mspoweruser.com/microsoft-forms-new-team-to-help-rewrite-core-windows-components-into-rust-from-c-c/)許多大型企業最近所承認的那樣，其記憶體使用量的顯著減少也是建立可擴展和**永續**平台的一大優勢。來自戲劇性的、有時有毒的 Scala 社區，**熱情且包容的**Rust 生態系統也是一個重要的吸引力，為探索這個新領域提供了動力。帶著這樣的厚望，讓我們開始我們的旅程吧！ --- 第 1 課：學習曲線是真的 ------------- 學習 Rust 並不像學習另一種語言。所有權、借用和生命週期等概念一開始可能會讓人望而生畏，使得原本瑣碎的程式碼變得極其耗時。儘管生態系統令人愉快（稍後會詳細介紹），但有時**您不可避免地需要編寫較低層級的程式碼**。例如，考慮我們的 API (Tonic/Tower) 的一個相當基本的中間件，它只報告計算持續時間： ``` impl<S, ReqBody, ResBody> Service<Request<ReqBody>> for MetricService<S> where S: Service<Request<ReqBody>, Response = Response<ResBody>, Error = BoxError> + Clone + Send + 'static, S::Future: Send + 'static, ReqBody: Send, { type Response = S::Response; type Error = BoxError; type Future = ResponseFuture<S::Future>; fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> { self.inner.poll_ready(cx) } fn call(&mut self, request: Request<ReqBody>) -> Self::Future { let clone = self.inner.clone(); let mut inner = std::mem::replace(&mut self.inner, clone); let started_at = std::time::Instant::now(); let sm = GrpcServiceMethod::extract(request.uri()); let future = inner.call(request); ResponseFuture { future, started_at, sm, } } } #[pin_project] pub struct ResponseFuture<F> { #[pin] future: F, started_at: Instant, sm: GrpcServiceMethod, } impl<F, ResBody> Future for ResponseFuture<F> where F: Future<Output = Result<Response<ResBody>, BoxError>>, { type Output = Result<Response<ResBody>, BoxError>; fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { let this = self.project(); let res = ready!(this.future.poll(cx)); let finished_at = Instant::now(); let delta = finished_at.duration_since(*this.started_at).as_millis(); // this is the actual logic let (res, grpc_status_code) = (...) crate::metric::record_call( GrpcKind::SERVER, this.sm.clone(), grpc_status_code, delta as u64, ); Poll::Ready(res) } } ``` 是的，除了泛型類型、泛型生命週期和特徵約束之外，您最終還需要為簡單的服務中間件編寫自訂的 Future 實作。請記住，這是一個有點極端的例子，旨在展示生態系統中存在的粗糙邊緣。*在許多情況下，Rust 最終可以像任何其他現代語言一樣緊湊。* **學習曲線可能會根據您的背景而有所不同。**如果您習慣了 JVM 處理繁重的工作並像我們一樣使用更成熟、更廣泛的生態系統，那麼可能需要付出更多的努力來理解 Rust 的獨特概念和範例。然而，一旦您掌握了這些概念和原語，它們就會成為您武器庫中極其強大的工具，即使您偶爾需要編寫一些樣板文件或宏，也可以提高您的工作效率。值得一提的是， [Google 在相當短的時間內成功地將團隊從 Go 和 C++ 過渡到 Rust，](https://www.theregister.com/2024/03/31/rust_google_c)並且取得了積極的成果。要平滑學習曲線，請考慮以下因素： - **閱讀官方[Rust Book 的](https://doc.rust-lang.org/stable/book/)封面**。不要跳過章節。理解這些複雜的概念將變得容易得多。 - **練習，練習，練習！**透過[Rustlings](https://rustlings.cool/)練習來建立肌肉記憶並採用 Rust 思維方式。 - **參與[Rust 社群](https://www.reddit.com/r/rust/)。**他們是一群令人難以置信的人，總是願意伸出援手。 - **利用 GitHub 的搜尋**功能尋找其他專案並向其學習。生態系統仍在不斷發展，與其他人的合作至關重要（只需注意許可證並始終做出貢獻）。我們將在下一篇文章中探討一些帶給我們啟發的專案。 --- 教訓 2：生態系仍處於成熟階段 --------------- Rust 的底層生態系統確實令人難以置信，擁有精心設計和維護的庫，並被社區廣泛採用。這些函式庫為建構高效能且可靠的系統奠定了堅實的基礎。然而，當你在堆疊中向上移動時，事情可能會變得稍微複雜一些。 ![](https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExeWNoejRsb2RhaGsybzQwdXJydjJzbHVpNjR6eW9udzdudjlvdWVjdiZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/l2SpOlC7JLROBEkO4/giphy.gif) 例如，在資料庫生態系統中，雖然針對關聯式資料庫存在像[`sqlx`](https://github.com/launchbadge/sqlx)和[`diesel`](https://github.com/diesel-rs/diesel)這樣的優秀函式庫，但對於許多非同步或非關聯式資料庫用戶端來說，情況會更加複雜。這些領域的高品質庫，即使被大公司使用，也往往只有**單一維護者**，導致開發速度較慢並且有潛在的維護風險。對於分散式系統原語來說，挑戰更為明顯，您可能需要實現自己的解決方案。這並不是 Rust 所獨有的，但與舊的/更成熟的語言相比，我們經常發現自己處於這種情況。從好的方面來說， **Rust 的生態系統對安全問題的反應令人印象深刻**，補丁迅速傳播，確保了應用程式的穩定性和安全性。到目前為止，圍繞 Rust 開發的工具也非常令人驚嘆。我們將在以後的文章中深入探討我們選擇的函式庫以及我們所做的決定。生態系統不斷發展，社區積極努力填補空白並提供強大的解決方案。準備好探索未知領域，並相應地分配資源以幫助維護，並回饋社區。 --- ### ……我有沒有提到我們是開源的？ > [Metroid](https://meteroid.com/)是一個現代化的開源計費平台，專注於商業智慧和可操作的見解。 **我們需要你的幫助！如果你有一分鐘時間，** [](https://git.new/meteroid) ![](https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExZDFvd2M3bnZ4OTF1dzBkcHh1NnlwemY1cTU5NWVjOThoZjU4a2U5biZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/XATW2O9w0hrmuIpvtu/giphy.gif) 您的支持對我們意義重大❤️ https://github.com/meteroid-oss/meteroid ⭐️ 在 Github 上為我們加註星標 ⭐️ --- 第 3 課：文件位於程式碼中 -------------- 當深入 Rust 的生態系統時，您很快就會意識到文件網站有時可能有點......好吧，稀疏。但不要害怕！真正的寶藏往往存在於原始碼中。許多庫都有**非常詳細的方法記錄，**並**在程式碼註釋中**包含全面的範例。如有疑問，請深入研究原始程式碼並進行探索。您經常會發現您尋求的答案，並對圖書館的內部運作有更深入的了解。雖然具有使用指南的外部文件仍然很重要，並且可以節省開發人員的時間和挫折感，但在 Rust 生態系統中，準備好在必要時深入研究程式碼至關重要。像[docs.rs](https://docs.rs)這樣的網站可以輕鬆存取公共 Rust 套件的基於程式碼的文件。或者，您可以使用 Cargo doc 在本機上產生所有依賴項的文件。這種方法一開始可能會令人困惑，但從長遠來看，花一些時間學習如何駕馭這個系統可能會非常有效。不用說，另一個有用的技術是尋找範例（**大多數庫在其存儲庫中都有一個`/examples`資料夾**）和使用您感興趣的庫的其他專案，並與這些社區互動。這些總是為如何使用該庫提供有價值的指導，並且可以作為您自己實施的起點。 --- 第四課：不要追求完美 ---------- 當開始使用 Rust 時，人們很容易會努力爭取最慣用和最高效能的程式碼。然而，大多數時候，以簡單性和生產力的名義進行權衡是可以的。 ![做完比求完美強](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fylenuk9pzgynzsvbwpf.png) 例如，使用`clone()`或`Arc`在執行緒之間共享資料可能不是最節省記憶體的方法，但它可以極大地簡化程式碼並提高可讀性。只要您意識到效能影響並做出明智的決策，**優先考慮簡單性是完全可以接受的。** 請記住，過早的優化是萬惡之源。首先專注於編寫乾淨、可維護的程式碼，然後在必要時進行最佳化。**不要嘗試進行微優化（**除非您確實需要）。 Rust 強大的類型系統和所有權模型已經為編寫高效、安全的程式碼提供了堅實的基礎。當需要優化效能時，請專注於關鍵路徑並使用`perf`和`flamegraph`等分析工具來辨識程式碼中的真正效能熱點。對於工具和技術的全面概述，我可以推薦[The Rust Performance Book](https://nnethercote.github.io/perf-book/introduction.html) 。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eyudtxuaeswhtc9porfc.png) **¹**這適用於您的整個創業歷程，包括籌款 --- 第五課：錯誤畢竟是好事 ----------- Rust 的錯誤處理非常優雅，具有`Result`類型和`?`運算符鼓勵明確的錯誤處理和傳播。然而，這不僅涉及處理錯誤；還涉及處理錯誤。它還涉及提供乾淨且資訊豐富的錯誤訊息以及可追蹤的堆疊追蹤。無需大量樣板在錯誤類型之間進行轉換。像`thiserror` ， `anyhow`或`snafu`函式庫對於這個目的來說是無價的。我們決定使用`thiserror` ，它可以簡化帶有資訊性錯誤訊息的自訂錯誤類型的建立。在大多數 Rust 用例中，您不太關心底層錯誤類型堆疊跟踪，而是更喜歡將其直接映射到域中的訊息類型錯誤。 ``` #[derive(Debug, Error)] pub enum WebhookError { #[error("error comparing signatures")] SignatureComparisonFailed, #[error("error parsing timestamp")] BadHeader(#[from] ParseIntError), #[error("error comparing timestamps - over tolerance.")] BadTimestamp(i64), #[error("error parsing event object")] ParseFailed(#[from] serde_json::Error), #[error("error communicating with client : {0}")] ClientError(String), } ``` 投入時間製作清晰且資訊豐富的錯誤訊息可以大大增強開發人員的體驗並簡化偵錯。這是一個小小的努力，卻可以產生顯著的長期效益。然而，有時，甚至在日誌位於使用者範圍之外的 SaaS 用例中，保留完整的錯誤鏈以及沿途可能有額外的上下文是很有意義的。我們目前正在試驗[`error-stack`](https://github.com/hashintel/hash/tree/main/libs/error-stack) ，這是一個由 hash.dev 維護的庫，它允許附加額外的上下文並將其保留在整個錯誤樹中。它作為`thiserror`之上的一層效果很好。它提供了一個慣用的 API，實際上將錯誤類型包裝在報告資料結構中，該資料結構保留了所有錯誤、原因和您可能加入的任何其他上下文的堆疊，在發生故障時提供大量資訊。我們遇到了一些問題，但這篇文章已經太長了，更多內容將在後續文章中介紹！總結 --- 使用 Rust 建立我們的 SaaS 一直是（而且仍然是）一段旅程。一開始是一段漫長而充滿挑戰的旅程，但也是一段非常有趣且有益的旅程。 - **使用 Scala 可以更快地建立我們的產品嗎？** 當然。 - **會有那麼有效嗎？** 或許。 - **我們還會像今天一樣充滿熱情和興奮嗎？** 可能不會。 Rust 促使我們以不同的方式思考我們的程式碼，接受新的範式，並不斷努力改進。 **當然，Rust 也有其粗糙的一面**。學習曲線可能很陡峭，而且生態系統仍在不斷發展。但這是令人興奮的一部分。除了技術面之外， **Rust 社群也絕對令人高興**。熱情的氛圍、樂於助人的意願以及對語言的共同熱情使這趟旅程變得更加愉快。 ![](https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExazJlZGppYjY5M3RwOG5sdHdudW94dzk4eXczZm5iMmN0YWUzdG10NyZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/sn39fEb1LcHPGQ4b6h/giphy.gif) 因此，如果您有時間和意願去探索一個新的、蓬勃發展的生態系統，如果您願意接受挑戰並從中學習，如果您需要表現、安全性和並發性，那麼**Rust 可能只是成為適合您的語言**。對我們來說，我們很高興能夠繼續使用 Rust 建立我們的 SaaS，不斷學習和成長，並看看這段旅程將帶我們走向何方。請繼續關注更深入的帖子，或在第一條評論中投票選出我們下一步應該做的事情。如果您喜歡這篇文章並發現它有幫助，請不要忘記給[我們的儲存庫](https://github.com/meteroid-oss/meteroid)一顆星！您的支持對我們來說意味著整個世界。 https://github.com/meteroid-oss/meteroid ⭐️ 流星星 ⭐️ 下次見，祝您編碼愉快！ --- 原文出處：https://dev.to/meteroid/5-lessons-learned-building-our-saas-with-rust-1doj

0個讚 0留言 48瀏覽

小編精選 - 技術文章翻譯 · 04月14日

遙測如何拯救我的開源平台

一開始是因為無法與使用者取得聯繫而感到沮喪，但很快就發展成了對平台流程的重新設計。我和我的團隊正在開發一個開源平台，幫助開發人員在 Kubernetes 中部署和管理他們的應用程式。我們一直在努力擴大我們的用戶群，並且努力已經開始顯現成效。安裝數量的不斷增加令人欣喜。然而，這是我們唯一能夠觀察到的事情。我們想了解更多。我們想知道用戶在我們的平台上做了什麼以及他們遇到了什麼困難。下面的短篇故事可以被認為是我們新創公司的#building-in-public條目，但我只是覺得它很有趣，想與你分享。 ### 支持我們🙏 我們知道 Kubernetes 可能很困難。這就是我們建立 Cyclops 的原因，這是一個**真正**面向開發人員的 Kubernetes 平台。抽象化 Kubernetes 的複雜性，並透過 UI 部署和管理您的應用程式。由於其平台性質，UI 本身是高度可自訂的 - 您可以更改它以滿足您的需求。 ![github 明星](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cfxdeq76dosfzv6ai5rb.gif) 我們正在將 Cyclops 開發為開源專案。如果您熱衷於嘗試一下，我們的[儲存庫](https://github.com/cyclops-ui/cyclops)中提供了快速入門指南。如果您喜歡所看到的內容，請考慮給我們一顆星來表示您的支持⭐ 使用者回饋🗣️ ------- 從一開始，我們就一直在努力與用戶交談並收集盡可能多的回饋。然而，事實證明這是一個問題。我們知道人們正在下載 Cyclops；在我們的 DockerHub 上，我們可以看到拉取的映像數量一天比一天多。問題是我們無法聯絡我們的用戶。**我們只能看到拉動的次數，而看不到拉動的人。** 為了與我們的用戶取得聯繫，我們建立了一個[Discord 伺服器](https://discord.com/invite/8ErnK3qDb3)。 Discord 是讓您的社群與您保持密切聯繫的好方法，正因為如此，我們才有辦法了解我們的用戶。所以我們開始和他們交談。回饋並不總是有建設性的… ![不滿意的用戶](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hpxp6hyw5a469yvze904.png) ……但大部分都是正面的。然而，有一個警告；我們得到的許多正面回饋來自與用戶的一對一會議。在這些會議中，我們可以比使用者自己更好地展示 Cyclops 的功能。事實證明，這是一個比我們想像的更大的問題。最近，我們實施了遙測，以便更好地了解我們的用戶如何使用 Cyclops。統計資料一開始出現，天哪，我們感到很驚訝。問題❗ --- 我們對 Cyclops 的安裝數量感到非常滿意。事實證明，我們認為 Cyclops 的安裝非常簡單且直接，這是正確的。但當我們開始使用它時，超過 60% 的用戶迷失了方向。那麼問題出在哪裡呢？問題是，當您想要將應用程式部署到 Kubernetes 叢集時，您必須提供 Helm 圖表形式的範本。我們建立了一些此類圖表的範例，並將它們發佈到我們的[開放儲存庫](https://github.com/cyclops-ui/templates)中。在我們所有的文件和部落格中，我們在開始使用 Cyclops 時向人們指出了該儲存庫。然而，它似乎並沒有流行起來。**已部署的應用程式數量仍然遠低於 Cyclops 啟動實例的數量。** 一個理論🧑‍🔬 ------- 親愛的讀者，這是一個有趣的事實：大多數線上讀者在網頁上花費的時間不到 15 秒（[來源](https://time.com/12933/what-you-think-you-know-about-the-web-is-wrong/)）。知道了這一點，我們的大多數用戶是否會瀏覽部落格和文件而錯過對我們模板存儲庫的引用？我們想測試這個理論。在我們的上一篇[部落格](https://cyclops-ui.com/blog/2024/03/26/devs-perspective)中，我們做了另一個關於 Cyclops 的教程，展示了它的好處。然而，對於這篇特定的文章，我們建立了一個特殊版本的 Cyclops。這個版本有什麼特別之處？**我們在建立新模組時為模板新增了預設值。** ![小變化](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/olpsmu9d7ep7spkppe83.png) 經過一段時間的統計，結果出來了。結果📊 --- 透過一個簡單的改變，我們看到用戶行為的**改善**，他們不再在使用我們平台的第一步中迷失方向！然而，它並沒有我們最初希望的那麼大的改進，但它肯定是在正確的方向上。我們問自己如何進一步改進這個問題。我們認為我們做到了🙌 自最新版本 (v0.3.0) 以來，我們重新設計了平台的流程。選擇模板不再是一個**輸入字段**，而是一個**下拉式選單**。 Cyclops 的每個實例都附帶幾個預製模板（儲存在我們的[模板儲存庫](https://github.com/cyclops-ui/templates)中），您可以自由使用和濫用。我們認為這將大大有助於向我們的用戶展示 Cyclops 的可自訂特性。 ![v0.3.0 下拉式選單](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pftn298lhl3nt9sexh0v.png) 但 Cyclops 的一個重要部分是它**能夠使用您自己的模板**，我們不准備在這一點上妥協！這就是為什麼我們新增了一個新的`Templates`選項卡，您可以在其中新增範本並管理現有範本。新增後，您的新範本將在下次部署應用程式時顯示在下拉清單中。學分🦔 --- 我們在本週早些時候發布了 v0.3.0，所以現在說它對我們的用戶有多大影響還為時過早，但我們對此抱有很高的期望！一旦足夠的時間過去，我們可能會分享統計資料，所以請務必關注我們來找出答案！如果不提及[PostHog](https://posthog.com/)作為我們正在使用的遙測提供程序，那就太可惜了，因為事實證明它非常有用。由於很難找到願意與您談論產品的人，因此收集統計資料可以讓我們更深入地了解用戶。如果您是為數不多的閱讀這篇文章超過前面提到的 15 秒的讀者之一，我希望您至少覺得它很有趣 😁 如果您有興趣為我們的專案做出貢獻，無論是透過編碼還是提供回饋，請加入我們的[Discord 社群](https://discord.com/invite/8ErnK3qDb3)並與我們交談！ --- 原文出處：https://dev.to/cyclops-ui/how-telemetry-saved-my-open-source-platform-30f5

0個讚 0留言 25瀏覽

小編精選 - 技術文章翻譯 · 12月16日

您付費工具的開源替代品

0個讚 0留言 275瀏覽

歡迎發文

💡 記錄日常工作的實踐、心得

💡 發表對生活和職場的感悟

💡 針對感興趣的事件發表隨筆或者雜談

💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣

💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）