Questions regarding openapi support in Rust web frameworks

I am about to start working on an HTTP service that has a hard requirement to have swagger/openapi support. I am familiar with Axum, and would have used it but unfortunately Axum has no support for openapi yet. See here

I checked other popular framework in the space: rocket, actix_web and warp and none of them have native openapi support.

I came across two third party library that provides the ability to bolt on openapi support regardless of the framework that is being used: Utopia GitHub - juhaku/utoipa: Simple, Fast, Code first and Compile time generated OpenAPI documentation for Rust and Aide GitHub - tamasfe/aide: An API documentation library but after evaluation I decided not to go with these two as it could make maintenance more problematic down the line.

The only framework I found that supported openapi natively was poem GitHub - poem-web/poem: A full-featured and easy-to-use web framework with the Rust programming language.

So I have two questions:

  • Are there other widely used framework out there, I might have missed that has native supports for openapi?
  • Has anyone seen or done benchmark for poem to compare it with the popular rust web frameworks? I can't seem to find anything on this, but it will be nice to see how poem compares in terms of performance before committing to it.
1 Like

I did this search myself awhile back and didn't find anything. We ended up using utoipa, but since our existing webserver is Warp, we had to manually create everything, and maintenance has been difficult.

Sorry I couldn't give you better information.

Hey,

Author of GitHub - juhaku/utoipa: Simple, Fast, Code first and Compile time generated OpenAPI documentation for Rust here speaking :slight_smile:

Sorry to hear that maintenance has been difficult. Though as it drives to be general library which follows closely OpenAPI spec in terms of usability it might not be the most intuitive in all the aspects. Furthermore since it is compile time generated there are some limitations on what is possible.

If there is something that could be improved or you would wish to exists in the library please file an issue or open a discussion in the Github page :slight_smile: That is only by users feedback we can work through to make it even better and more ergonomic to use.

Though hardest part is to find a way to better integrate it with frameworks and how the warp is designed it is quite hard to make it seamless especially if traits are used as path operation handlers.

1 Like

(this is somewhat off of memory since I haven't looked into this web service in a few months)

Yeah, that is kind of what I would say--the way Warp is, we couldn't really integrate utoipa directly into it. So we sort of had to maintain parallel code where we manually wrote out all the Utoipa stuff and had to make sure it matched what was happening in the code. I don't necessarily blame Utoipa for that.

We also had some issues where we were procedurally generating filters and handlers, which meant that we had to procedurally generate the Utoipa objects as well, which took some work. Also, we had problems where multiple filters called the same handler, and we had to end up writing stub methods for the purpose of having something to decorate.

Perhaps if we had instead written the Warp code using macros it would be easier--but we already had our web server and were trying to add OpenAPI to it, rather than integrating it from the ground up.

Anyway, I didn't really mean to disparage Utoipa, just that it was the best thing to use with our existing Warp server and it still wasn't very easy.

Salvo has openapi support now.
You can view this example: salvo/main.rs at main · salvo-rs/salvo · GitHub

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.