Switch from actix-web to a better maintained web framework

[houqp]

From #75 (comment). We should evaluate both warp and https://github.com/tokio-rs/axum.

[houqp]

rocket has added async support, so we should evaluate them as well.

[Smurphy000]

What is your criteria for evaluation? I have started using rocket for a little project I am working on, so if there are some features you want to compare I can share what I have learned about rocket to compare with other frameworks.

[houqp]

I don't have a very objective rule here. I prefer frameworks that have intuitive APIs without layers of unnecessary abstractions and coupling. So mostly coding style I guess. Code base with simple and right level of abstractions makes it easier maintain, debug, optimize and troubleshoot.

I have been ignoring rocket mainly because they didn't have tokio 1.x support. Author of rocket is a really solid engineer, so I have high hope for it :)

But honestly, I am happy if we can migrate to any of these 3 frameworks because I am really not a fan of actix-web :( I think feature wise they should be pretty comparable.

[ekroon]

I am looking at the different options and currently there are some outstanding issues that would be impacted by / could influence the decision:

• HTTP2 Support #16
• Add support for websockets #40
• Support Arrow Flight endpoint #77
• Add RFC7231 Accept header parsing  #80

At this point I investigated Axum the most:

• HTTP2 Support #16 and Support Arrow Flight endpoint #77 (GRPC) on a single endpoint is described here. Apparently not super easy, but working solution available.
• Add support for websockets #40 is supported, see: axum::extract::ws
• Add RFC7231 Accept header parsing  #80 is not supported as it is in Actix.

Apart from that, it seems that compiling certain routes is problematic for the Rust compiler, as described in rust-lang/rust#88322 and tokio-rs/axum#200. tokio-rs/axum#200 (comment) lists a possible workaround that might be sufficient. I did find similar problems for Warp, see seanmonstar/warp#507.

I think I am quite positive about Axum. Regardless of that, how would we go about this change anyways? In #67 (comment) I suggested having integration tests through an HTTP api, which I think would be very helpful for migrating the codebase without having (too much ;)) regressions.

Coincidentally, tokio-rs/axum#200 (comment) has an example how we could go about that with Hyper. The Zero To Production series also uses this approach: blog and code.

[houqp]

Sorry @ekroon I have been busy with datafusion lately, so I won't have much time to help with the web framework evaluation this week. If you are feeling good about axum, then please feel free to give it a stab :)

I am all for integration tests over unit tests. So if you want to contribute integration tests to help with the migration, that would be great.

[houqp]

@ekroon i am looking into this now, let me know if you are already working on it.

[ekroon]

@houqp I am working on the integration tests. I lost a lot of time on figuring out on why only in the integration test in Linux the brotli crate of actix causes linker issues with the brotli crate in datafusion / parquet. With Axum this would not be a problem because it uses the same brotli crate as in parquet implementation. Warp I didn't check.

Workaround for Actix is disabling compression feature (through no-defaults = true)

[houqp]

Sounds good, I will leave it to you then :D You can push your WIP branch to a PR if you need any help from me to look into blocker issues. I am cool with disabling compression for actix to get the integration test to pass. I don't think it matters from integration test's point of view.

[marklit]

Actix underwent 4 or 5 rewrites under the original author so its codebase has had a lot of thought put into it. The new lead of the project looks to be getting ready for the second major yearly release. The project has had 4M downloads, underpins popular projects like MeiliSearch. I wouldn't discount this project unless there are some serious holes in its functionality that you're uncovering.

Axum is about six months old, has around 320 commits and is still under very heavy development: https://github.com/tokio-rs/axum/commits/main There have only been 32K downloads of the package according to https://crates.io/crates/axum whereas Rocket has passed 1M downloads.

The developer behind Warp works on a lot of open source Rust projects; I'm not sure where this person's focus will be in the next 12-18 months. Warp is very low-level and is aimed to be both a client and a server which might not be the right feature match for this project. The developer's other HTTP server project, Hyper has had 31M downloads. It's also low-level so you'll want to check it already has the features you need.

I'd suggest either considering Rocket or if you do want to go for Axum, consider becoming a frequent contributor to that project.

[ekroon]

@marklit I am currently working on porting the Actix specific tests to integration tests. After that, we can try out the different options in this issue.

[johannescpk]

@marklit You might want to also consider that axum and warp are wrappers around hyper and are tower-compatible (e.g. warp services can be used in axum as well), so they both stand on the shoulders of a rock solid core.

[houqp]

I did a quick PoC with both axum and rocket, see: https://github.com/houqp/roapi/tree/qp_axum and https://github.com/houqp/roapi/tree/qp_rocket.

For my very limited and uncomprehensive test, rocket port was doing around 29k rps, axum 33k rps and actix 39k. But I think rocket's performance issue is the less concerning part, after all, we can help them fix these performance bottlenecks. What I really don't like about rocket is it's heavily dependent on macros. These procedure macros are not as easy to study and debug compared to simple structs and functions that axum has. Most of the UX problem these macros addressed can be easily handled by simple generic functions that are a lot easier to maintain. The rocket community also seems to be in an inactive state right now for the last couple months.

I am not that concerned about downloads and popularities. Flask is the most popular web framework in the python community, and it's a pretty bad framework of choice for serious python projects.

I think we should go with axum for now. I really like its simplicity and debuggability compared to all other choices. @ekroon let me know if you need any help with the integration tests.

[ekroon]

@houqp Last weeks were super busy with work and other stuff. Let me make a PR with what I have later today, as coming week I probably don't have a lot of time either.

[houqp]

no worries @ekroon , was just checking with you so I am not stepping on your toes ;)

[houqp]

Thank you everyone for the input, especially @ekroon for the research and integration test :) we have now fully migrated to axum.