You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: "Motore provides the core middleware abstraction for Volo. Volo uses Motore as the foundation of its core middleware abstraction layer, on top of which RPC-related functions and implementations are built."
7
7
---
8
8
9
-
Understanding the relationship between them is crucial for in-depth use of Volo, framework extension, or developing custom middleware.
9
+
Understanding the relationship between them is crucial for in-depth use of Volo (such as framework extension, developing custom middleware, etc.).
10
10
11
-
In simple terms: **Motore defines the two general and core asynchronous middleware abstract interfaces, `Service` and `Layer`, while Volo is the main user of these abstract interfaces and the implementer in specific scenarios (RPC)**.
11
+
In simple terms: **Motore defines the two general and core asynchronous middleware abstract interfaces, `Service` and `Layer`, while Volo is the user of these abstract interfaces and the implementer in specific scenarios (RPC)**.
12
12
13
13
Motore is more general and can theoretically be used in any place that requires asynchronous service abstraction. Volo is more specific, focusing on the RPC field and utilizing Motore's abstraction to implement RPC-specific functions.
14
14
@@ -21,15 +21,15 @@ Motore is an independent Rust crate ([cloudwego/motore](https://github.com/cloud
21
21
Motore mainly defines two core Traits:
22
22
23
23
1.**`Service<Cx, Request>`**:
24
-
*Represents a functional unit that processes requests and asynchronously returns a `Result<Response, Error>`.
25
-
*This is the most basic component in Motore and can represent a client, a server, or the middleware itself.
26
-
*Its core is the `async fn call(&self, cx: &mut Cx, req: Request) -> Result<Self::Response, Self::Error>` method. It receives a context `Cx` and a request `Request`, and asynchronously returns the result.
24
+
* Represents a functional unit that processes requests and asynchronously returns a `Result<Response, Error>`.
25
+
* This is the most basic component in Motore and can represent a client, a server, or the middleware itself.
26
+
* Its core is the `async fn call(&self, cx: &mut Cx, req: Request) -> Result<Self::Response, Self::Error>` method. It receives a context `Cx` and a request `Request`, and asynchronously returns the result.
27
27
28
28
2.**`Layer<S>`**:
29
-
*Represents a "decorator" or "factory" used to wrap and enhance a `Service`.
30
-
*It receives an inner `Service` (generic `S`) and returns a new, wrapped `Service` (`Self::Service`).
31
-
*`Layer` itself does not directly handle requests but is used to build and compose `Service` chains (i.e., middleware stacks).
32
-
*Its core is the `fn layer(self, inner: S) -> Self::Service` method.
29
+
* Represents a "decorator" or "factory" used to wrap and enhance a `Service`.
30
+
* It receives an inner `Service` (generic `S`) and returns a new, wrapped `Service` (`Self::Service`).
31
+
*`Layer` itself does not directly handle requests but is used to build and compose `Service` chains (i.e., middleware stacks).
32
+
* Its core is the `fn layer(self, inner: S) -> Self::Service` method.
33
33
34
34
Motore aims to provide a protocol-agnostic, reusable middleware infrastructure. It focuses on the abstraction itself, rather than a framework for a specific application domain like RPC (as Volo is), but Motore can serve as a foundation for building such frameworks.
35
35
@@ -44,23 +44,23 @@ Motore also provides some auxiliary tools, such as `ServiceBuilder` for chaining
44
44
Volo is a full-featured RPC framework that supports Thrift and gRPC. Volo **directly depends on and is deeply integrated with Motore** as the foundation of its internal middleware system.
45
45
46
46
1.**Dependency and Re-export**:
47
-
*Volo directly depends on the `motore` crate in its `Cargo.toml`.
48
-
*Volo **re-exports** Motore's core Traits at the entry point of its library (`volo/src/lib.rs`): `pub use motore::{Service, layer, Layer, service};`. When you use `volo::Service` or `volo::Layer` in a Volo project, you are **actually using the Traits from Motore**.
47
+
* Volo directly depends on the `motore` crate in its `Cargo.toml`.
48
+
* Volo **re-exports** Motore's core Traits at the entry point of its library (`volo/src/lib.rs`): `pub use motore::{Service, layer, Layer, service};`. When you use `volo::Service` or `volo::Layer` in a Volo project, you are **actually using the Traits from Motore**.
49
49
50
50
2.**Specific Implementation**:
51
-
*The Volo framework extensively uses the abstractions provided by Motore to build its functionality. For example:
52
-
*Load balancing (`LoadBalanceLayer`) is a component that implements Motore's `Layer`.
53
-
*Features like timeout control, logging, and metrics collection can be integrated by implementing Motore's `Layer`.
54
-
*The RPC service handling logic (Handler) written by the end-user, as well as the client-side calling logic generated by the framework, will be wrapped into a form that conforms to the Motore `Service` interface.
55
-
*Volo provides many `Layer`**implementations** that are **specific to the RPC scenario**, such as handling Thrift or gRPC protocol details, service discovery integration, etc. These implementations all follow the `Layer` interface defined by Motore.
51
+
* The Volo framework extensively uses the abstractions provided by Motore to build its functionality. For example:
52
+
* Load balancing (`LoadBalanceLayer`) is a component that implements Motore's `Layer`.
53
+
* Features like timeout control, logging, and metrics collection can be integrated by implementing Motore's `Layer`.
54
+
* The RPC service handling logic (Handler) written by the end-user, as well as the client-side calling logic generated by the framework, will be wrapped into a form that conforms to the Motore `Service` interface.
55
+
* Volo provides many `Layer`**implementations** that are **specific to the RPC scenario**, such as handling Thrift or gRPC protocol details, service discovery integration, etc. These implementations all follow the `Layer` interface defined by Motore.
56
56
57
57
3.**User Interaction**:
58
-
*Volo users generally configure and add middleware through the APIs provided by `Client::builder()` or `Server::new()`. These APIs internally use `motore::ServiceBuilder` or the low-level `motore::layer::Stack` to apply the `Layer`s provided by the user to the `Service`.
59
-
*If users need to write custom middleware, they also need to implement the `motore::Layer` Trait (or directly implement `motore::Service` to wrap another Service).
58
+
* Volo users generally configure and add middleware through the APIs provided by `Client::builder()` or `Server::new()`. These APIs internally use `motore::ServiceBuilder` or the low-level `motore::layer::Stack` to apply the `Layer`s provided by the user to the `Service`.
59
+
* If users need to write custom middleware, they also need to implement the `motore::Layer` Trait (or directly implement `motore::Service` to wrap another Service).
60
60
61
61
## Why is Motore needed?
62
62
63
63
Separating the core abstraction (Motore) from the framework implementation (Volo) brings several benefits:
64
64
65
65
1.**Modularity and Reusability**: The abstractions and some basic Layers (like timeout) defined by Motore are generic and can be used by projects other than Volo to write middleware and services.
66
-
2.**Separation of Concerns**: Motore focuses on providing stable, efficient, and ergonomic core abstractions. Volo, on the other hand, focuses on the business logic and protocol details of the RPC framework.
66
+
2.**Separation of Concerns**: Motore focuses on providing stable, efficient, and ergonomic core abstractions. Volo, on the other hand, focuses on the business logic and protocol details of the RPC framework.
0 commit comments