path to tower-service 1.0

[hawkw]

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

[hawkw]

I went ahead and assigned everyone who might have opinions on this, hope that's not too annoying. :)

[hawkw]

Quick ping — how do other maintainers (especially @seanmonstar, since it's potentially relevant to hyper 1.0) feel about this proposal?

[davidpdrsn]

I think your proposal sounds good! I'm up for helping investigating the proposed changes and porting tower-http and axum to see how they work in practice.

One thing though: It all depends on the timeline that we agree on but I don't think we should necessarily wait for new features to stabilise in Rust. I think we should focus on coming up with a design that makes sense given what Rust looks like today, otherwise I'm afraid we'll never ship 😕

I also think we should consider a 1.0 of tower-layer (although less important). Personally I'm happy with it as is and not aware of any proposed changed.

tower-service being 1.0 would be huge for the ecosystem so I'm excited about thisk! axum isn't going 1.0 anytime soon but someday we'll have to think about it.

[LucioFranco]

I think this makes a lot of sense. I believe most of the features we are waiting on are almost ready (and should be on nightly).

My main question though is we should 1.0 tower with hyper, so @seanmonstar how close is hyper to something like a 1.0?

[hawkw]

@davidpdrsn

One thing though: It all depends on the timeline that we agree on but I don't think we should necessarily wait for new features to stabilise in Rust. I think we should focus on coming up with a design that makes sense given what Rust looks like today, otherwise I'm afraid we'll never ship confused

Yeah, I strongly agree with this. I think we should investigate the suggested changes that are potentially possible today, see if they work, and not worry about the Shiny Future too much. If there are significant language changes that impact the design of Service in the future, it would probably be fairly reasonable to consider a 2.0 release.

I also think we should consider a 1.0 of tower-layer (although less important). Personally I'm happy with it as is and not aware of any proposed changed.

Yeah, I agree; I left that out of this issue because it seemed out of scope. Fortunately, though, I think stabilizing tower-layer should be much more straightforward; I don't think there are any significant potential changes we might want to investigate. It just requires that the Service trait be stabilized, since it depends on tower-service.

@LucioFranco:

I think this makes a lot of sense. I believe most of the features we are waiting on are almost ready (and should be on nightly).

Hmm, what language features are you thinking about here? If you mean impl Trait in trait associated types, I think that may potentially make using the Service trait with async-await much nicer, but I don't think it significantly impacts the trait's design. Was there something else you had in mind?

My main question though is we should 1.0 tower with hyper, so @seanmonstar how close is hyper to something like a 1.0?

I think the point here is that if hyper 1.0 occurs before tower-service is stable, it will need to implement its own Service trait, rather than depend on tower-service. If we can stabilize tower-service before hyper releases its 1.0, it will probably be possible for hyper to continue to use Tower's Service trait. Stabilizing Service before hyper 1.0 seems like the ideal goal for us to aim for...but I'm not totally sure about Sean's planned timeline for that?

[LucioFranco]

I'd like to add another note https://github.com/awslabs/smithy-rs/ is a pretty big consumer of tower so we should also consider their use.

Hmm, what language features are you thinking about here? If you mean impl Trait in trait associated types, I think that may potentially make using the Service trait with async-await much nicer, but I don't think it significantly impacts the trait's design. Was there something else you had in mind?

Yeah I am thinking GAT for the token style. So this would align with the splitting the ready and call part of the Service trait.

I think the point here is that if hyper 1.0 occurs before tower-service is stable, it will need to implement its own Service trait, rather than depend on tower-service. If we can stabilize tower-service before hyper releases its 1.0, it will probably be possible for hyper to continue to use Tower's Service trait. Stabilizing Service before hyper 1.0 seems like the ideal goal for us to aim for...but I'm not totally sure about Sean's planned timeline for that?

Our goal should be 100% to have hyper 1.0 with Service imo.

In addition, I think the big pain point with tower is poll_ready since this infects things like call requiring it to take &mut self. I think there are some improvements we can make ergonomically without changing the current service trait. If we provide ways for users to not have to interact with the Service trait directly via like mappers etc.