Hyperlane Framework Design Principles V10

[eastspire]

Hyperlane extensively adopts Tokio-based read–write locks (RwLock) in both the service layer and the configuration layer. By leveraging the await mechanism, tasks that need to acquire a lock under contention will wait in order rather than panic, ensuring deterministic and stable concurrent behavior.
In practice, the overhead of read–write locks on Context is minimal, and lock contention is almost negligible.

Context is wrapped with Arc<RwLock<…>>, making the cost of clone significantly lower than copying an entire request or response object. This design frees developers from worrying about performance overhead caused by cloning requests or responses, and eliminates the complexity of dealing with ownership and lifetimes for mutable requests and mutable responses.

All request- and response-related data in Hyperlane is centrally stored within Context, providing a single and well-defined source of truth. This approach abandons the traditional functional-style design commonly found in web frameworks, which separates “request input parameters” and “response return values”. Through the interior mutability of Context, Hyperlane can more naturally support complex scenarios and advanced extension requirements.

On top of this, the design of the ServerHook trait aligns more closely with object-oriented programming principles. Service behavior is organized around objects and lifecycles, improving the overall extensibility and maintainability of the framework.

[eastspire]

debug comment test