1 //! Trait object [`Service`] instances 2 //! 3 //! Dynamically dispatched [`Service`] objects allow for erasing the underlying 4 //! [`Service`] type and using the `Service` instances as opaque handles. This can 5 //! be useful when the service instance cannot be explicitly named for whatever 6 //! reason. 7 //! 8 //! There are two variants of service objects. [`BoxService`] requires both the 9 //! service and the response future to be [`Send`]. These values can move freely 10 //! across threads. [`UnsyncBoxService`] requires both the service and the 11 //! response future to remain on the current thread. This is useful for 12 //! representing services that are backed by [`Rc`] or other non-[`Send`] types. 13 //! 14 //! # Examples 15 //! 16 //! ``` 17 //! use futures_util::future::ready; 18 //! # use tower_service::Service; 19 //! # use tower::util::{BoxService, service_fn}; 20 //! // Respond to requests using a closure, but closures cannot be named... 21 //! # pub fn main() { 22 //! let svc = service_fn(|mut request: String| { 23 //! request.push_str(" response"); 24 //! ready(Ok(request)) 25 //! }); 26 //! 27 //! let service: BoxService<String, String, ()> = BoxService::new(svc); 28 //! # drop(service); 29 //! } 30 //! ``` 31 //! 32 //! [`Service`]: crate::Service 33 //! [`Rc`]: std::rc::Rc 34 35 mod layer; 36 mod sync; 37 mod unsync; 38 39 #[allow(unreachable_pub)] // https://github.com/rust-lang/rust/issues/57411 40 pub use self::{layer::BoxLayer, sync::BoxService, unsync::UnsyncBoxService}; 41