poem VS axum

https://github.com/poem-web/poem is one Rust framework with swagger definitions out of the box.

There is one: Poem[1]

The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi

[1] https://github.com/poem-web/poem

TypeSpec is great, but if you're working with Rust and you're about to write a new project that will require an OpenApi spec sooner or later, I'd like to recommend a web framework that has spec generation baked in:

https://github.com/poem-web/poem (see poem_openapi)

All you need to do is derive a trait on your response structs and in return you get an almost perfectly generated spec. Unions, objects, enums are first class citizens.

Also, if you're from coming from PHP, the controllers feel very much like symfony controllers.

P.s. Please do recommend an ORM that would feel closer to doctrine. I miss doctrine.

I've used FastAPI/Pydantic before as well and it was a very good experience. It has been a while since I used them though, so I forget exactly how they compare, but I do recall it wrote most of the OpenAPI spec. for you. I will also agree when I saw utoipa and aide they seemed to require more boilerplate even though I have not done an actual comparison. Poem, on the other hand, seems very neat and clean and doesn't have any duplication that I can see. Here is the [TODO example](https://github.com/poem-web/poem/blob/master/examples/openapi/todos/src/main.rs).

The example at https://github.com/poem-web/poem/tree/master/examples/openapi/auth-apikey works without issues for me.

'Poem', it turns to nicer to play with for me than 'Axum'. Example of web socket chat https://github.com/poem-web/poem/blob/master/examples/poem/websocket-chat/src/main.rs

If you need built-in OpenAPI support, I can recommend Poem.

If OpenAPI is important, then you may to consider https://github.com/poem-web/poem instead of axum. It isn't nearly as widely used, but it should still be compatible with everything else.

Poem: More rigid and less popular and aims to be easier https://github.com/poem-web/poem

Did you check out Poem? It seems promising, with openapi generation built in already.

For this example, we will use axum, a web framework that works on top of tokio.

If your lambda handles multiple endpoints of your API, the crate axum facilitates the routing within the lambda.

We’ll use Axum with Tokio to build a web backend, Tracing for logging, and Serde for serialization and deserialization.

After I read a bit about axum [1], it says it's a relatively thin wrapper on top of hyper [2], a fast and correct HTTP library.

In other words, what can be done with NGINX, it can be achieved with axum (assuming you know Rust).

It looks interesting, I'm not going to lie!

[1] https://github.com/tokio-rs/axum

[2] https://crates.io/crates/hyper

If you are familiar with API development in Rust, you may recognize this syntax from Axum. This puzzling question piqued my curiosity and led me to build Cairo, where I re-implemented some key Axum concepts in a simpler way as a learning exercise. I’ve long been fascinated by the intermediate + advanced concepts library authors employ to make their interfaces feel frictionless. Rust sits in a brilliant space because of the way it melds high-level expressiveness with low-level control and performance. One of the ways it accomplishes this is using macros.

Let's create a small prototype in Rust to demonstrate the concept using Tera and Axum.

There are some proposals on how to do it already such as https://github.com/tokio-rs/axum/issues/1698.

Moreover, I especially like where Rust is right now in the web space. It really feels like there’s a lot of smart people working on the next generation of web development tools - it feels like the place to be. There are a range of great open-source web dev tools that are just reaching critical levels of maturity. Axum, which I used to build Prodzilla, feels ready for out of the box web dev, and is crazy-performant, as I write about later. More recently available is Loco, a Rails-like framework for building web applications in Rust that's picking up steam. And in dev-tooling and hosting there’s Shuttle, a 1-line hosting solution for Rust backends.

CryptoFlow is a full-stack web application built with Axum and SvelteKit. It's a Q&A system tailored towards the world of cryptocurrency!

You also get to specify the accepted HTTP method of the URL via axum::routing. To answer its name, modularity, Axum also supports nested routes as we'll see later in this series. Next is the layer, a method used to apply tower::Layer to all routes before it. This means that routes added after the layer method will not have such a layer applied to their requests. In our case, we used the layer to add tracing to all HTTP requests and responses to our routes. This is needed for proper logging. The tower_http::trace::TraceLayer can even be really customised.