Replacing FastAPI with Rust: Part 2 - Research

[dbanty]

A place for questions and comments about this blog post.

[mosheduminer]

BTW, there is a typo (completely instead of complete) on line 40 of the draft. And I think you maybe meant to link to it?

I notice you didn't mention one of the features of FastAPI mentioned in the "teaser" comment - the fact that the OpenAPI schema is defined with the same code as the validation code. Perhaps that is what you meant all along when discussing OpenAPI, but it wasn't obvious to me.

[dbanty]

Wow, thanks for the extremely fast feedback 😅. I will link it here once the edited version of the post is up (and change the title). I was very much trying to summarize the features of the options I looked at, but I'll try to make them more clear. Maybe a quick bulleted list for each?

Also, you're the first person to ever comment on any discussion I've created, so thank you🙏!

[mosheduminer]

Well, I have to say that you really grabbed my interest with the idea of replicating FastAPI in rust... Whether it will be just a combination of tooling, or a new framework.

Unfortunately, I'm not yet so good with rust, I occasionally go back to work on https://github.com/sirixdb/sirix-rust-client or the CLI/shell I am building using that, but it's tough going 😅.

[mosheduminer]

Honestly (from re-reading the blog post draft, and a quick look at rweb docs), rweb sounds really promising. Lack of maintnence would probably be the biggest issue for me personally. As far as docs go, it a bit sparse, though I'd mention that you'd probably not find many projects documented as nicely as FastAPI.

[dbanty]

I feel the same way, unfortunately lack of maintenance really is a deal killer if I’m looking for something to recommend for production workloads.

Maybe I should do a prototype with both rweb and Paperclip + actix-web, then weigh the amount of work for each before deciding. That would be the next blog post or two though 😁