And it went really well. So far the only changes I noticed were the web::block
error api (due the the use of tokio’s spawn_blocking now instead of actix-threadpool), the move of Service’s Request from being an associated type to a generic, the move to insert_header
and append_header
, and the inclusion of the correct JsonPayloadError
so I don’t need to depend on awc to get that type :)
Here’s what I’ve gotten done
- background-jobs-actix updated to actix-rt 2.0.2
- background-jobs-sled-storage revived on actix-rt 2.0.2
- actix-fs (unpublished) updated to actix-rt 2.0.2
- actix-webfinger updated to actix-web 4.0.0-beta.3
- actix-form-data updated to actix-web 4.0.0-beta.3
- http-signature-normalization-actix updated to actix-web 4.0.0-beta.3
- pict-rs updated to actix-web 4.0.0-beta.3
- pict-rs-proxy updated to actix-web 4.0.0-beta.3
- pict-rs-aggregator updated to actix-web 4.0.0-beta.3
- aode-relay updated to actix-web 4.0.0-beta.3
My current Big Project, Hyaenidae, has not been updated because actix-session doesn’t yet have a beta release, but I’m keeping my eye out.
One question I have about the Service API changing is: why. I’m interested to know if there’s a specific benefit for moving Request to be a generic instead of an associated type. I don’t deal with Service much outside of writing a few middlewares, so this change doesn’t make a ton of sense to me.
Some general notes: I feel like blocking operations are faster now with tokio’s spawn_blocking underneath than before when it was actix-threadpool. I don’t have any benchmarks to demonstrate this, but I think I noticed an improvement when uploading files with actix-form-data + actix-fs in pict-rs while testing the upgrade.
@nutomic@lemmy.ml I think maybe we should wait for the next actix-web to come out of beta, but what do you think?
Agreed, the only reason to update now would be if we are waiting for a certain feature or bug fix. But we could already implement the updates without merging that PR.