Motivation

Tower has been used in production for over three years. Since the Service trait is intended to provide a common abstraction and compatibility interface across libraries, the definition of the Service trait is factored out into the tower-service crate so that it can remain stable even as other parts of the Tower ecosystem are changed. A significant number of major crates depend on tower-service, including hyper, tonic, warp, and axum. In most cases, these are public API dependencies. This means that these crates cannot currently release 1.0 versions while they expose tower-service in their public APIs.

The last time a breaking change was made to the Service trait was November 2019; this was in order to transition from futures 0.1 to std::future. While there have been a number of proposed improvements to the Service trait (e.g. #110, #136, #137, #319, #408, #412, #626), most of these have not ended up being practical, or require future language features that are not currently available on stable Rust.

Therefore, I think it's time to have a serious conversation about stabilizing the Service trait.

Proposal

In order to stabilize tower-service, I think we should do the following:

1. Set an approximate time-frame for a stable release. If possible, coordinate with other libraries that have public API dependencies on tower-service and wish to release 1.0 versions (e.g. hyper).
2. Thoroughly investigate proposed Service trait changes. Before stabilizing Service exactly as it exists right now, we should look into all the potential breaking changes that have been suggested, investigate whether they are possible, and assess the potential benefits of making them. This includes ideas like Service::disarm, tokens, splitting Service into PollReady and Call traits, etc. I think the best way to assess these ideas is to actually implement them in a branch. To really determine the benefits and drawbacks of these changes, it would probably also be good to fork a crate that uses tower-service, and try to update it to use the modified version. If this isn't practical, we should at least try to update a non-trivial example project; at the very least, we should be able to test out tower::balance and get the load-balancing example to work.
3. Make any breaking changes. If any of the proposed breaking changes actually work and have noticeable benefits...we should make them, and release non-1.0 versions with that change, so that the ecosystem can try it out.
4. Actually publish a 1.0 release. :)

Once we stabilize tower-service, we may want to consider the path to stability for tower-layer as well, but I think that's not as important.

Outstanding questions

• What should the Service trait actually look like?
• What should we use Service's blanket impl for? See service: Impl Service for async functions #657