-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decide what to do with tower #5
Comments
After consideration, taking into account feedback in tower-rs/tower#753 as well as reading through https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html and linked resources, it seems clear that the async story is not yet ready for tower+tokio like systems. On top of that we clearly run into:
So instead... I think, we'll cut our losses, consider what we learned from it... and,.... move back to tower itself. On top of that I start to doubt that it really makes sense to try to wrap everything. For the runtime it does make sense, but for tower I do think it's a bit much... Instead I start to like more and more the way Axum handles it. Lastly, if we go for regular tower services it will also play a lot nicer with hyper as-is. It is also probable that the combination of being able to run on rust stable + using the regular tower ecosystem, would allow others to adopt rama a lot easier. |
That
rama
is to be built in the "tower" spirit is clear. However at the moment we make use of https://github.com/plabayo/tower-async rather then the original https://github.com/tower-rs/tower. Reason being that only with a lot of boxing one can make use of async functions within aTower
Service.For now
tower-async
fulfils that needs. However:call(): Send
: tracked in Tracking Issue for return type notation rust-lang/rust#109417. It's not even certain thatRTN
will make it;On top of that it means we have to put in the work to maintain an entire alternative tower ecosystem ourselves.
tower-rs/tower#753 was opened to help decide that.
So far it seems that the
impl_trait_in_assoc_type
usage would be the way to go and would allow us to make use of tower as-is, and refer to futures. Where we need async opaque types we can make use oftype Future = impl Future<...>
. However what is less clear is if they also want to go for&self
instead of &mut selfand whether they want to get rid of
poll_ready` in the default contract. Which would still be desired.As there is a lot of unclarity here, and as tower-async does work just fine for now and we already spent a lot of time on it, for now we can just keep it as-is. Once there is more clarity in regards to the direction of tower, and once we have time for it, we can look back it it. Anyone who wishes can also provide feedback here in regards to tower usage within rama and the direction we might want to take.
The text was updated successfully, but these errors were encountered: