『壹』 Electron替代方案，rust跨平台GUI框架TAURI之hello world
tauri 是一個新興的配明判跨平台GUI框架。與electron的基本思想相似，tauri的前端實現也是基於html系列語言。tauri的後端使用rust。官方形容，tauri可以創建體積更小、運行更快、更加安全的跨平台桌面應用。
詳細的介紹可以自行去官網查看：
官網
Github
本人使用windows10系統。本hello world，實現了以tauri搭建桌面程序，在html頁面點擊按鍵後，槐陵由後台rust反饋信息。
效果如下：
tauri 需要用到rust、nodejs，編譯器可使用vscode
官方文檔有比較詳培改細的環境搭建步驟，可參閱：
https://tauri.studio/docs/getting-started/intro
其中，當搭建完環境，使用命令
yarn add tauri
安裝tauri包時，可能會出現報錯：
pngquant failed to build, make sure that libpng-dev is installed
此錯誤並不影響使用，可忽略。
初始化完成的tauri程序結構如上圖所示。默認情況下dist菜單用於存放實際的頁面文件。具體可在tauri.conf.json文件中進行設置。
具體實現步驟如下：
『貳』 減少rust編譯後程序體積
第一步：
編敬祥譯release版本
第二步：
strip 命令
擴展
整優化等級
通過修改默認優化亮液搏等級方式減少體積，以cpu換空間，如果不是必要，建議不要改
在Cargo.toml中新增下面配置
開啟 LTO
減少體積，增加鏈接時埋孫間也是一個取捨問題
在Cargo.toml中新增下面配置
『叄』 使用 Rust 構建 gRPC 伺服器
弗洛里安·克魯姆 ( Florian Krumm ) 在Unsplash上拍攝的照片
一旦我了解了gRPC和Thrift，就很難再回到使用更具過渡性的基於 JSON 的 REST API 或SOAP API 了。
兩個著名的RPC框架 gRPC 和 Thrift 有很多相似之處。前者源自谷歌，後者源自Facebook。它們都易於使用，對多種編程語言都有很好的支持，並且都具有高性能。
最有價值的功能是多種語言的代碼生成以及伺服器端反射。這些使 API 本質上是類型安全的。使用伺服器端反射，可以更輕松地 探索 API 的模式定義，而無需閱讀和理解實現。
Apache Thrift在 歷史 上一直是一個流行的選擇。然而近年來，由於缺乏來自 Facebook 的持續支持，以及與fbthrift的分叉分叉，慢慢失去了人氣。
與此同時，gRPC 已經趕上了越來越多的功能，擁有更 健康 的生態系統。
GRPC（藍色）與 Apache Thrift（紅色）的比較。谷歌趨勢
gRPC、fbThrift 和 Apache Thrift 之間的 GitHub 明星 歷史 。https://star-history.com
到今天為止，除非您的應用程序以某種方式隸屬於 Facebook，否則沒有充分的理由考慮 Thrift。
GraphQL是另一個由 Facebook 發起的框架。它與上面的兩個 RPC 框架有很多相似之處。
移動 API 開發的最大痛點之一是一些用戶從不升級他們的應用程序。因為我們想保持向後兼容性，我們要麼必須在 API 中保留舊的未使用欄位，要麼創建 API 的多個版本。GraphQL 的一個動機就是解決這個問題。它被設計成一種「查詢語言」，允許客戶端指定它需要的數據欄位。這使得處理向後兼容性變得更容易。
GraphQL 在開發移動 API 以及面向公眾的 API（例如GitHub）方面具有巨大價值。因為，在這兩種情況下，我們都無法輕易控制客戶端的行為。
但是，如果我們正在為 Web 前端構建 API 或為內部後端服務構建 API，那麼選擇 GraphQL 而不是 gRPC 幾乎沒有什麼好處。
以上是迄今為止網路框架的一個小概述。除了網路，我們還需要決定應用伺服器的語言。
基於Stack Overflow 調查：「六年來，Rust 是最受歡迎的語言。」 盡管學習曲線相對陡峭，但它的類型安全、優雅的內存管理、廣泛的社區支持和性能，都使 Rust 成為一種非常有吸引力和有前途的後端服務開發編程語言。
Rust 是最受歡迎的語言。2021 年 Stackoverflow 調查
我們也開始看到 Rust 在行業中得到越來越廣泛的採用：Facebook、Dropbox、Yelp、AWS、Google等。很明顯，Rust 將繼續增長並繼續存在。
這就是我們將在今天的教程中看到的內容——在 Rust 中使用 gRPC 構建一個小型伺服器。
使用以下命令安裝 Rust：
如果您以前安裝過 Rust，我們可以通過以下方式對其進行更新：
讓我們仔細檢查rustc（Rust 編譯器）和cargo（Rust 包管理器）的安裝版本：
有關安裝的更多信息，請查看https://www.rust-lang.org/tools/install。
運行以下命令創建一個新的「Hello World」項目：
讓我們編譯並運行程序：
這顯示了我們到目前為止的文件結構：
gRPC 使用協議緩沖區來序列化和反序列化數據。.proto讓我們在一個文件中定義伺服器 API 。
我們定義了一個書店服務，只有一個方法：提供一個書本 id，並返回有關該書的一些詳細信息。
我們將使用tonic創建我們的 gRPC 服務。將以下依賴項添加到Cargo.toml文件中：
為了從 生成 Rust 代碼bookstore.proto，我們tonic-build在 crate 的build.rs構建腳本中使用。
將以下內容添加到build.rs文件中：
需要特別指出的一件事是，我們添加它.out_dir(「./src」)是為了將默認輸出目錄更改為該src目錄，以便我們可以更輕松地查看生成的文件，以達到本文的目的。
在我們准備編譯之前還有一件事。tonic-build依賴於Protocol Buffers 編譯器將文件解析.proto為可以轉換為 Rust 的表示。讓我們安裝protobuf：
並仔細檢查 protobuf 編譯器是否安裝正確：
准備編譯：
有了這個，我們應該src/bookstore.rs生成一個文件。此時，我們的文件結構應該如下所示：
最後，是時候將服務放在一起了。替換為main.rs以下內容：
正如我們所見，為了簡單起見，我們並沒有真正的圖書設置資料庫。在這個端點中，我們只是返回一本假書。
運行伺服器的時間：
很好，我們在 Rust 中啟動並運行了 gRPC 伺服器！
正如開頭所說，gRPC 最初給我留下了深刻的印象，因為它具有做伺服器反射的能力。它不僅在服務開發過程中很方便，而且還使與前端工程師的溝通變得更加容易。因此，如果不解釋如何為 Rust 伺服器添加它，那麼結束本教程是不完整的。
將以下內容添加到依賴項中：
更新build.rs。需要更改的行用// Add this注釋標記。
最後，將其更新main.rs為以下內容。
有許多 GUI 客戶端可以使用 gRPC Server，例如Postman、Kreya、bloomrpc、grpcox等。為了簡單起見，我們將使用命令行工具grpc_cli。
安裝：
並測試我們的第一個 gRPC 端點：
看起來它有效！我的朋友，這就是我們在 Rust 中構建 gRPC 伺服器的方式。
這就是今天的內容。感謝閱讀和快樂的編碼！與往常一樣，源代碼可在GitHub 上獲得。
『肆』 為什麼Rust這樣的語言還需要C/C++編譯器
需要用 VS 的鏈接器，應該是需要支持 FFI 的原因。Windows 是 Rust 承諾要支持的主要平台之一，這意味著，Rust要有能力和Windows上的靜態庫和動態庫來交互。這時候，MSVC的ABI就是繞不過去的一個問題。可以參考 Rustup 的官方文檔對Windows平台的描述，rust-lang-nursery/rustup.rs。 Windows平台上有兩套ABI，一個是MSVC，一個是MinGW。所以你其實有兩個選擇，要麼安裝 msvc，然後
rustup install stable-x86_64-pc-windows-msvc
要麼安裝 MinGW，然後
rustup install stable-x86_64-pc-windows-gnu
在 Rustup 的文檔上有這么一句話 By default rustup on Windows configures Rust to target the 32-bit MSVC ABI, that is the i686-pc-windows-msvc target triple. 所以，默認安裝的話，你需要安裝 msvc。