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