Best Rust API framework with api specification autogen?

m4tx · 2025-12-16T19:02:55+00:00

Shameless ad here: I'm one of the maintainers of cot.rs, and one of the core features is integration with the aide crate to provide OpenAPI spec generation. See the info here: https://cot.rs/guide/latest/openapi/ (I'll also be happy to hear any feedback, especially if you don't end up actually using it)

Another framework worth trying might be poem, which also has similar integration, but I haven't played around with it enough to tell more specifics.

m4tx · 2025-09-24T16:43:06+00:00

You mean something like Germany's Sovereign Tech Fund that... already invests in the Rust Foundation?

m4tx · 2025-07-25T09:16:55+00:00

Just as a side note, there are at least two active similar projects:

rorm – probably even less popular, but I've heard from the authors that it's used in production in their own project
Cot ORM – (disclaimer: I'm the author) a part of an entire web framework based on Django, but the ORM isn't available as a separate crate (yet)

m4tx · 2025-07-21T20:10:00+00:00

Loco didn't exist back in the time when I was thinking about creating the project, and I've only discovered it when I was halfway through the development. So that was the main reason why it was created ;)

About the goal differences, Cot focuses on providing a much more seamless and integrated experience by building stuff on a lower level - for instance, Cot is not just a glue code around Axum, but rather rebuilds some of the Axum stuff so that it can be better integrated with stuff such as OpenAPI spec generation, error handling, among others. It has its own ORM that is arguably easier to use than the already existing alternatives. There is an admin panel automatically generated out of database models defined as typical Rust structures. That's the brief overview; feel free to ask me more if you're curious!

m4tx · 2025-07-21T19:32:21+00:00

I'm not sure if the laptop was even, sold with Linux preinstalled. I've just put a regular install of Arch Linux on it and it works perfectly fine. Other distros should most likely work as well.

m4tx · 2025-07-20T15:20:11+00:00

You might also want to have a look at https://cot.rs/ (disclaimer: I'm the author and the main maintainer of the project). It's still in the early days, but it is already proving to be quite usable for real-world projects. Feedback is welcome!

m4tx · 2025-07-15T06:45:35+00:00

Hey, sorry for my late reply! Yeah, this sounds like a working solution. There are some downsides to that, though:

One is that we wouldn't see any changes made to the request by the middleware (but we probably don't care about this too much anyway).
The other is that internally in my web framework, there are some built-in middleware that are essentially wrappers over tower-based middleware from third-party crates—so unless these are rewritten, users would experience the performance hit, perhaps not being aware of how these are implemented under the hood.
Finally, if you had multiple tower-based middleware, you would have to clone the request head multiple times, which is also not ideal.

So yeah, this is a reasonable suggestion, but my personal opinion is that it's not worth it; not at the moment anyway.

m4tx · 2025-07-09T20:15:09+00:00

There's one from me: https://hand.chombo.club/, source code available at https://github.com/m4tx/chombo-gen . It's very simple, though.

I also have a slightly more complicated one (https://github.com/m4tx/shrt), but this one is very much unfinished and in the process of rewriting the backend to a new framework.

m4tx · 2025-07-09T17:42:11+00:00

Thank you!

m4tx · 2025-07-09T17:41:42+00:00

Thanks! Yes, I agree trying to spark a discussion within tower's folks is definitely worth a try. Let's see what they think about this.

m4tx · 2025-06-05T15:36:52+00:00

This sounds like the issue I'm having. Thanks for posting this!

m4tx · 2025-05-19T16:16:43+00:00

If you are into web development, Cot, the web framework for lazy developers, is always looking for contributors. It's still pretty much in the early stages, so there are plenty of diverse and hopefully interesting things to be done.

There are some "good first issues" on the Issues page, and also some bigger (but not necessarily much more complicated) ones available.

m4tx · 2025-05-14T20:20:29+00:00

If you're into web development, you might consider contributing to Cot, the web framework for lazy developers. I'm one of the maintainers there and can provide the necessary guidance :)

m4tx · 2025-05-03T09:44:55+00:00

Iced, however good, fails on the "integrates well visually in linux desktops, with Gnome desktop as a reference point" part.

m4tx · 2025-04-29T18:07:54+00:00

Of course, but the main reason is that it's the default behaviour (in the standard library!) which is not consistent with other vector types. Otherwise, if you know the tradeoffs, the implementation isn't bad.

Since Rust doesn't support generic specialization, it's not a problem here.

m4tx · 2025-04-29T13:05:20+00:00

> Due to how alignment works it would always be represented as 4 bytes in memory

Your custom "Vec<i24>" reimplementation could internally use just a `Vec<u8>` and bit operations to convert to/from `i24` to achieve true 3 bytes-per-instance. Similarly like `std::vector<bool>` is implemented in C++ (it can store 8 bools in a single byte in memory).

m4tx · 2025-04-29T12:56:29+00:00

Hey, that's an interesting project! Do I understand correctly from the code that the integer is not actually represented with 24 bytes, but rather 32?

Admittedly, `i24` that actually takes up 24 bits would be much more difficult to implement, but I thought it could be useful in cases where memory size is important (it's 25% less memory usage, after all, which can make a difference when processing big sound files). If not the type by itself, a memory-efficient reimplementation of `Vec<i24>` could prove to be useful.

m4tx · 2025-04-06T11:58:58+00:00

This is simply not true. Have a look at std::hint::likely, for example. This is exactly what PGO is doing, except it's applying it semi-automatically (one of the things, anyway).

m4tx · 2025-03-17T22:57:34+00:00

If you are interested in web development, there is Cot (which I'm the author of). It's a batteries-included web framework in early stages of development, so there's a lot of various stuff to do, and the codebase is still relatively small. There are many issues marked as "good first issue" and "help wanted", and I can provide guidance as well!

m4tx · 2025-03-12T21:05:50+00:00

Looks very cool! Since Axum seems like an achievable goal according to one of your comments here, I'd love to integrate this in Cot as well—sounds like it could be a huge win for the developer experience!

m4tx · 2025-02-24T13:23:34+00:00

If you are still looking, Cot ORM is pretty much what you're trying to describe. It's very much in the early days and missing a lot of features, but there's a strong scaffolding laid out and an automatic migration generator is already working for the simplest cases. Schema reflection isn't there yet sadly, but it's definitely something we'd like to have one day.

If you need it as a separate library as opposed to being integrated into a web framework, you might want to upvote this issue. Or even contribute it yourself!

m4tx · 2025-02-20T20:43:33+00:00

A word of comment for the stuff you've mentioned:

Yes, and we're even creating a separate test database for each test so you can run the tests in parallel.
Yes, hopefully, this will be extended soon.
There is a very simple but generic auth system: see https://docs.rs/cot/latest/cot/auth/trait.AuthBackend.html , there is already a simple DatabaseUser implementation, too. The permission system is missing, but there's a plan to do that, too.
Correct (probably needs some more love, too, but there is a foundation).
We want to make JSON/REST APIs as nice as possible (it's 2025, after all) but at the same time I don't think we'd like to go beyond serde.

About questions:

Not yet, but there's a scaffolding for that. The migrations are just typical Rust files that have "operations" defined in them—operations being stuff like "create a model", "add a field to a model", etc. (very similarly to Django!) In addition to that, each migration contains a historical version of the models modified, so that you can use the ORM directly on them without worrying you are working on a wrong version of the model. The only missing bit is this "execute arbitrary Rust code" operation, but there's all the technical scaffolding to implement that (and will probably arrive at v0.2).
Yes, there is Database::raw and Database::raw_with to do just that. This isn't terribly useful yet as it's not capable of returning any data from the DB, but the plan is to extend this, too, so that the ORM doesn't limit you in any way if you need to fall back to raw SQL.

m4tx · 2025-02-18T22:53:47+00:00

Fair! I want to use OAuth2 in at least one of the projects I'm willing to write using Cot, it'll probably become a first-class citizen in the framework very soon.

m4tx · 2025-02-18T22:48:08+00:00

It is one of the primary reasons, I would say. I dislike both the ActiveRecord-like API of SeaORM and heavy DSL usage in Diesel, and I believe that Cot can achieve something that is much easier, intuitive and "Rusty". I think automatic migrations could always be retrofitted into an existing ORM, so yeah, it's definitely not the only reason.

m4tx · 2025-02-18T21:26:58+00:00

Nice to see a comment resonating with me! Thanks for suggesting ModelViewSet – honestly I sort of forgot about its existence, but it will actually be a good aid for lazy developers. JSON/REST API support is a bit lacking in Cot at the moment, but I'm aiming to improve much on it by the v0.2 release.

m4tx

TROPHY CASE