🤖 Introduction to Volo
Volo is a high-performance, easy-to-use Rust RPC framework open-sourced by the ByteDance service framework team.
The Volo framework has very low overhead and provides command-line tools and a flexible middleware design, allowing developers to easily get started and enjoy the development experience that Rust offers.
Project GitHub link:https://github.com/cloudwego/volo
This article introduces the changes since the Volo-HTTP 0.3.0 version.
🚀 Feature Highlights
1. Improved Client Usability
In previous applications, to pursue performance, we used a lot of generics in the <span>Client</span>, which led to extremely complex type definitions and confusing error messages, increasing the cognitive load for developers.
To address this issue, we optimized the encapsulation of the <span>Client</span> in the new version by wrapping the internal <span>dyn Future</span> with a <span>Box</span> at the outer layer. This change ensures that the types are simple and easy to use while introducing almost no additional performance overhead. The specific comparison is as follows:
- Old Version (0.3.0): Users needed to construct a
<span>DefaultClient</span>with complex generic types. - New Version (0.4.0): Users can directly use the
<span>Client</span>, with clearer types and simpler usage.
2. Support for HTTP/2
The new version now provides full HTTP/2 support for both server and client, and the client also supports connection pooling functionality.
🔧 Other Changes
1. Removal of Default <span>Target</span>
Considering that the default <span>Target</span> of the client was not frequently used but complicated the selection logic of <span>Target</span>, we have removed it in this version.
However, we have added the <span>TargetLayer</span>, which can enforce the <span>Client</span> to set the <span>Target</span>, thus providing a similar experience to before.
- With the removal of the default
<span>Target</span>, the default<span>Host</span>configuration has also been removed. We have refactored the original<span>Host</span>Layer to make it more flexible, now supporting four modes:<span>None</span>,<span>Auto</span>,<span>Force</span>, and<span>Fallback</span>. - The default
<span>callee name</span>has been removed, and it is recommended to use the<span>TargetLayer</span>‘s<span>with_callee_name</span>method instead. This method is mainly used for accessing HTTPS services via IP address and requires setting SNI (Server Name Indication). <span>RequestBuilder::full_uri</span>has been removed. We recommend implementing this functionality through the<span>Layer</span>method rather than directly manipulating in the<span>RequestBuilder</span>. Relevant examples will be published later.
2. Other Optimizations and Adjustments
- Unified Naming:
<span>DefaultLB</span>and<span>DefaultLBService</span>have been renamed to<span>DefaultLb</span>and<span>DefaultLbService</span>. - Removal of Deprecated Items: Removed deprecated
<span>ClientRequest</span>,<span>ServerRequest</span>,<span>ClientResponse</span>, and<span>ServerResponse</span>types. - Code Simplification: Reduced some unnecessary generic constraints.
- Log Fixes: Fixed an issue where an infinite loop of warning logs would occur when the
<span>discover</span>‘s<span>watch channel</span>was closed. - New Proxy Support: Added
<span>HttpProxyLayer</span>to support HTTP proxies defined in RFC7230. - Observability: The HTTP server now supports
<span>SpanProvider</span>.
🐞 Bug Fixes
- Now using
<span>DiscoverKey</span>as<span>Discover::Key</span>, replacing the previous<span>(FastStr, u16)</span>tuple. This resolves unexpected caching issues caused by domain names with ports.
Major Changes
1. Simplified Client
- The following complex type aliases have been completely removed:
<span>ClientMetaService</span><span>ClientService</span><span>SimpleClient</span><span>DefaultClientOuterService</span><span>DefaultClient</span><span>Client</span>‘s generic type has been adjusted from internal service (<span>S</span>) to request body and response body (<span>ReqBody</span>and<span>RespBody</span>). In most scenarios, users can directly use the<span>Client</span>without worrying about its generic types.
2. Support for HTTP/2
- To support HTTP/2, we introduced new Cargo features:
<span>"http1"</span>and<span>"http2"</span>. - The default features have been updated to
<span>["default-client", "default-server"]</span>. - Please note that
<span>"default-client"</span>and<span>"default-server"</span>only enable HTTP/1.
3. Removal of Default <span>Target</span>
- The following functions related to the default
<span>Target</span>have been removed from<span>ClientBuilder</span>: <span>ClientBuilder::address</span><span>ClientBuilder::host</span><span>ClientBuilder::with_port</span><span>ClientBuilder::with_scheme</span><span>ClientBuilder::target_ref</span><span>ClientBuilder::target_mut</span><span>Host</span>Layer has been refactored, and<span>ClientBuilder::default_host</span>has been updated to<span>ClientBuilder::host_mode</span>.<span>RequestBuilder::full_uri</span>has been removed.
📄 Complete Changelog
volo-http-0.3.0…volo-http-0.4.0[1]
References[1]
volo-http-0.3.0…volo-http-0.4.0: https://github.com/cloudwego/volo/compare/volo-http-0.3.0…volo-http-0.4.0