paperclip VS rweb

The first bit I tried was following pieces of the official actix-web tutorial in order to get a tiny little web server started locally. This went fine, but was actually a big mistake as that tutorial teaches you to use macros to define endpoints which, at the time of writing, Paperclip does not support.

The biggest issue with Paperclip is that it only currently supports OpenAPI v2. There is work in progress to add v3 support, but it's just that: in progress. This means that if I really want to supplant FastAPI with this actix-web w/ Paperclip combo, I'm going to have to write my own v3 implementation. There is a GitHub Issue which talks about the intended strategy for achieving this being somehow based on converting a v2 spec to v3. I'm not sure how possible this will be considering there are some important features missing from v2. It makes more sense to me for this to be a different feature via cargo flag (or at least a different module).

rweb is pretty simple. it's based on warp, but with rocket-like #[get("/product/{id}")] which is like Flask's @app.route("/product/").

I wrote a PR this weekend to give FastAPI like UX to rweb! https://github.com/kdy1/rweb/pull/56

This crate has an implementation for the Handler trait which I used to model my own Handler trait for an actix-web Service. Using my own struct which implemented that trait suddenly made the "this is not Send" error messages simple enough to decipher. I was able to get the thing to actually compile, but it required using a few unwrap()s on errors which were not Send. I could probably go back and figure out how to wrap or map those errors to something simpler to make my implementation less fragile, but I was already annoyed enough at this implementation that I was headed toward rweb anyway.

All of that is to say rweb is a possible solution, but not a likely one. The product seems great, and if the code functions as well as the brief examples indicate, this is the best option from a code perspective (oops, spoilers!). Given my concerns about the community, I would have to be comfortable forking and maintaining my own version of this framework in the event that I need changes and can't wait months for a PR to be reviewed. Even if that's not the case, I'll certainly have to write much more complete documentation for my teammates to be able to use this project effectively. I'm not mortally opposed to any of that, but I'd rather avoid it if I can.