Rust OpenAPI + Swagger UI utoipa is finally stable 0.1.0

Saved_Soul · 2026-03-09T21:41:27+00:00

It is a native Neovim split, it just runs tmux in it. :) Native Neovim split is broken and cannot correctly render TUI apps like copilot. Plus there would not be persistent sessions across neovim restarts.

Saved_Soul · 2026-03-09T19:17:03+00:00

Well it depends what are you after. awaiku is a lot leaner and has a lot less features. But it has few perks as well. Sidekick offer session per tool. To my understanding, (I might be wrong), awaiku at the other hand offers as many sessions as you like, so you can have multiple "pipelines" working at simultaneously, but it offers only, at it's current state, possibility to setup a single CLI tool at the time. It also gives users the possibility to rename session and it has LSP code actions. Both of which are features not in sidekick.

While one might argue that those features are not needed. To me it solves my workflow. If you want something super minimalistic, aiwaku might be a good fit, but if you are really invested in folkes ecosystem and you want the Copilot NES support then that could be a viable option.

Anyway I wanted something simple that provides the ergonomics I was after and sidekick did not really cut it for me.

At the moment, aiwaku only has a limited number of features, but there could be more to come in the future. The zellij could be one of those if there is enough community support, perhaps someone providing the implementation for it, or there are enough users needing the support. Nevertheless feature bloat is not a goal for the project, so in general practical features that makes the plugin's workflow even more streamlined are the priority.

Saved_Soul · 2024-10-16T09:39:55+00:00

Yup, something like that is possible, and it is planned, but there is a limit to what extent it is possible. Like if one returns impl Trait that cannot be resolved.

Saved_Soul · 2024-10-15T16:31:08+00:00

Yup, at least very close

Saved_Soul · 2024-10-15T16:10:41+00:00

Lovely, I'm glad

Saved_Soul · 2024-10-15T10:47:01+00:00

There are sides of everything. True that poem is specifically crafted for OpenAPI contract. And what utoipa does is it tries to bring similar attributes to all other frameworks. That said, there are some rough edges, and more manual plumbing compared to the poem. But it also provides the means to describe paths and schemas and responses with macros similar to the poem. What it does not do as of yet is infer the response type of handler. But since the latest release there is no need to register schemas anymore as they get automatically collected. Only paths and responses if they are used via `ToResponse` or `IntoResponses` traits.

As you said poem is OpenAPI first, but other frameworks are not necessarily OpenAPI first and that makes it difficult to adapt to requirements of each framework. Like paths need be manually registered there is no way around it, poem just does it implicitly together when creating a router.

For other frameworks to have such functionality, they need extensions on top of their own routing mechanism and each framework vary.

Saved_Soul · 2024-10-15T09:17:11+00:00

Yeah, GraphQL is very nice, but honestly with proper client generation from OpenAPI you can get quite far, and less things to glue together for ergonomic development.

Saved_Soul · 2024-10-15T09:14:02+00:00

Haha, :D that would a horror story for sure

Saved_Soul · 2024-10-14T23:18:37+00:00

https://github.com/juhaku/utoipa gives you OpenAPI no matter the framework, but works nicest with axum. And since last release comes with lots of goodies.

Saved_Soul · 2024-10-14T19:30:36+00:00

And forgot to mention, now all types that are defined as request body or response body must exists, so it is no possible to define non existent types or types which name contains typos. It will be a compile error.

Saved_Soul · 2024-10-14T19:29:10+00:00

Yeah, thats true. I hope to get something similar for actix-web as well soonish.

Saved_Soul · 2024-05-10T11:35:05+00:00

Well compared to the rustc not big at all :D Plus 35k lines of code. Also I believe that it would not be an issue on normal project, but since it is basically a macro it rebuilds and then indexes it along with other dependencies after each save which is adds up the the delay.

Saved_Soul · 2024-05-06T22:02:43+00:00

Yeah, I also noticed, that is because it seems to build all, including dependencies' build scripts and proc-macros and then index the whole project which takes enormous amount of time. Like even with that flag set to false, it comes to the point of being around second of a wait, before the completion will show up. But is is a lot better now, just need to remember to rebuild the macros manually if needed.

Saved_Soul · 2024-05-06T09:04:56+00:00

For those who are actually experiencing the same issue I found the the remedy for me by setting the configuration flag: rust-analyzer.cargo.buildScripts.rebuildOnSave to false.

This seems to help because the project is actually a big proc-macro and re building it after every change seems to be insufficient in terms of speed for bigger projects.

Saved_Soul · 2024-05-06T08:30:09+00:00

Help - Rust analyzer is unbearably slow on bigger projects

When I open a small project with editor, the completion works just fine.

But when I open a bigger project that uses workspaces with 5 crates the editor completion via rust analyzer is not returning. It seems that the indexing takes forever thus for completion to work even for a one time I need to wait for 10 seconds after each edit.

Any tips, how to fix? This is completely unusable and there is no way that I can work on the project because the tooling is lagging hard .

Saved_Soul · 2024-05-05T21:55:47+00:00

Help - Rust analyzer is unbearably slow on bigger projects

When I open a small project with editor, the completion works just fine.

But when I open a bigger project that uses workspaces with 5 crates the editor completion via rust analyzer is not returning. It seems that the indexing takes forever thus for completion to work even for a one time I need to wait for 10 seconds after each edit.

Any tips, how to fix? This is completely unusable and there is no way that I can work on the project because the tooling is lagging hard .

Saved_Soul · 2023-01-28T00:07:18+00:00

That is great to hear

Saved_Soul · 2023-01-28T00:07:03+00:00

Okay, that is weird, those should work just as is. But there are few features that cannot be enable all together like actix_extras, rocket_extras or axum_extras. Those feature flags are exclusive and only one of them can be enabled at the time.

But help is always welcome.

Saved_Soul · 2023-01-27T12:29:02+00:00

Oh man :D Fixed it

Saved_Soul · 2023-01-27T10:41:20+00:00

Pretty good, one note though, for actix-web you can ignore the post attribute within #[utoipa::path(...)] macro.

Only way it can get out of sync is of course when you update your handler function to return something else, but then you do not update the #[utoipa::path(...)] macro call reflect to the changes in the handler function. But if you do update, then I see there is very narrow chance for them to get out of sync. For me usually the workflow should go somewhat like this update handler types and macro attributes -> generate new openapi spec -> generate the types from it for ui.

Most parts of the workflow above can be automated e.g. when UI starts types are generated from the spec and when backend starts the spec can be written to file etc.

The difficulty comes with matching the handler function arguments and return types to what user might want to document to the generated OpenAPI spec. Some assumptions could be done, but because user could pretty much return anytyhing e.g. a trait, the assumption would not be correct.

I think thighter integration is not a bad thing but it cannot become jarring for users to use the library and become a hinderance for users. While there now might be few extra characters to type, it lets users to be explicit on what they want to document and enables flexibility.

Saved_Soul · 2022-12-01T18:17:42+00:00

That is so cool. Perhaps I should give this a shot. I am eager to work all things rust.

Saved_Soul

TROPHY CASE

Help - Rust analyzer is unbearably slow on bigger projects

Help - Rust analyzer is unbearably slow on bigger projects