Update to actix-web 1.0

[pjenvey]

Edit: switched out this issue to solely focus on upgrading actix-web 1.0

[fzzzy]

Running the above commands currently errors out at cargo update because of version conflicts with ring. I've seen this before. It requires choosing versions of all dependencies which depend on ring such that they all depend on the same version of ring. So, this will take some work to investigate a working combination of versions.

[jrconlin]

Looks like actix-web is working on 1.0.0 which updates a bunch of that.

Unfortunately. looks like there are also a number of breaking changes.

[jrconlin]

So, most of the changes are reasonably easy to deal with in the code. Two are a lot less so.

Apparently actix dropped rolling your own middleware, and having a TestServer.

[pjenvey]

actix-web's migration to 1.0 doc:

https://github.com/actix/actix-web/blob/master/MIGRATION.md

describes many of the App's initialization call changes that affects us, e.g. App::with_state(T) -> App.new().data(T)

A couple examples of conversion of custom Middleware -> Transform trait here:

https://github.com/actix/examples/commit/14eed91fcd73aa65247e145ed394d86989a93ee3#diff-24d9e194249630e11f90021cf6cecafd

The first rc is slated for release after the current beta3: https://github.com/actix/actix-web/issues/722#issuecomment-489384976

[pjenvey]

I'm postponing this upgrade for now. The upgrade of everything except middleware isn't too bad. We have an extensive use of middleware that calls into our extractors (FromRequest) and the 1.0 upgrade complicates this.

actix-web 1.0 upgrade requirements:

• [x] Minor API changes
• [x] Initialization/App setup changes
• [x] Handlers now return impl Future vs actix-web's FutureResponse
• [x] Reapply actix-web#637: (actix-web#894)

for the middleware:

• [x] Switch from the 0.7 Middleware trait to the new more low level Service Trait + an associated Transform
• [ ] Convert separate start/response methods to a single call method (like a Python decorator). Some of this is done
• [x] Service::call methods call into an inner service (a chain of Services). Some of our middlewares seem to require wrapping the inner service in a Rc<RefCell<S>>
• [ ] Using HttpRequest (and thus our associated extractors we heavily call in middlewares) is now discouraged from use within Service::call. You can get an HttpRequest by consuming a ServiceRequest: but then you're unable to reconstruct a ServiceResponse, a required argument to the next Service call. DbTransaction and PreConditionCheck call into extractors numerous times. Allowing reconstruction of the original ServiceRequest is unsafe. Solving this requires a large change for these 2 middlewares. Nikolay's looking into alternatives (like maybe FromRequest can take a ServiceRequest?)

[fzzzy]

🎉🏆💯🎆