Determine the future of tower-web

[carllerche]

Currently, tower-web fits the niche of being the only Rust web framework that is:

• async
• macro based
• compiles on stable

There is a space for it to evolve. I have also mentioned in the past the plan to merge with Warp. At a high level, the goal for that would be to update the macros to generate warp filters.

However, reality is that I don't have time to focus on this right now. My time is going to be entirely consumed on updating Tokio, Tower, mio, bytes, etc... to std::future and release the next major version of those libraries. So, until that is done, I can't spend any dev time on tower-web.

Given that, I see two options.

a) deprecate tower-web and suggest to use warp (and revisit come the end of 2019 / 2020 if time becomes available).
b) pull in additional contributors who would be able to do the development (significant) and I can focus on mentoring that group.

I would like to see b) happen, but that would require people to step up as it would be significant work. The default option would be a), to deprecate tower-web.

If any are interested in taking on development, please comment in here and we can see if something can get going.

[bstrie]

Thanks for the update regarding integration with warp, one of the things that's kept me from looking at it too seriously is the uncertainty regarding whether or not it was going to be sunsetted out in favor of tower-web. I believe I speak for everyone when I say that it's completely understandable that you have enough on your plate already this year. :)

If you believe that it's possible to imagine a future version of tower-web that exists solely as a code generation layer on top of warp, then for the moment it seems to suggest that volunteers could focus on improving warp and getting it ready to someday serve as such a foundation (unless you think it's already there...?).

[mfcastellani]

Hi. I'm using tower-web as my first option in some projects and I believe no other framework fits that niche you said. I would like to help to maintain the project alive.

[carllerche]

@bstrie you interested in participating in dev?

@mfcastellani great!

I will let this issue stay open a bit, and maybe next week reach out to any who express interest and we can have a gitter meeting or something like that.

[bstrie]

@carllerche I recently began a job where one of our components makes use of tower-web, so I could ask my employer if they would like to sponsor me contributing to it. However, note that they were thinking about taking a look at warp due to the fact that they want to be able to handle websockets and HTTP on the same port, which (I believe) warp supports but tower-web does not currently; presumably integrating warp with tower-web would render moot this kind of feature disparity. I understand you and seanmonstar don't have a lot of time, but since you're the two who best grok what a merger of warp and tower-web would entail, then if you could put your heads together and give us a roadmap or design document then it would go a long way towards letting third parties pick up the work.

[carllerche]

@bstrie

Yeah, I avoided worrying about websockets specifically because warp had it, and the long term goal is to merge.

At a high level, my goal is to reduce tower-web to the macro stuff that will generate something... the exact details of what that something is is TBD.

I think the best first step is to use tower::Service as the integration point. So:

1. reduce tower-web to only code / macros that generate a T: Service.
2. Improve warp's support for integrating and filtering over T: Service.

A lot of what exists today in tower-web has already been extracted.

[bstrie]

Thanks, that's a good starting point. The other question I have is if you have any ideas off the top of your head regarding breaking changes that you've been wanting to make to tower-web's API, since this is probably a good excuse. If you have significant changes in mind, then combined with warp integration it might make sense to fork tower-web into a new project entirely (how's "twerp" for a terrible proposed name? :P )

[carllerche]

The set of breaking changes might be something best determined as a group. I think, the primary goal, will be to simplify and reduce. (I also need to reload the context as I dumped it from the cache).

[qmx]

I can't commit full capacity but I'm happy to help wherever I can - I'm using tower-web in production with great success!

[tarcieri]

@carllerche I am potentially interested in contributing, but more as someone who can triage and potentially work on open issues, as opposed to feature work

[pid42]

is this still ongoing ? @carllerche .
If yes, I would be interested in getting involved