Python async has been a big mess. I haven’t looked back since moving to a Go + GRPC + Protobuf stack. I would highly recommend it.
Show HN: FastOpenAPI – automated docs for many Python frameworks
41–50 of 85 posts
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#42Python async has been a big mess. I haven’t looked back since moving to a Go + GRPC + Protobuf stack. I would highly recommend it.
I really enjoy Python's asyncio. I'm a big fan of aiohttp and the entire aio* ecosystem.
Then there's Rust's Tokio for the things that need performance.
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#43After years of development - Now I prefer declarative approach. Specs first, generate the code from it and implement required Interfaces. One great too for that is TypeSpec[0]. This also allows thinking about the API first and ensures that what's documented is what's implemented. [0] https://typespec.io
> Now I prefer declarative approach
Doesn't most people? Until you're no longer in the happy path of whatever you use to generate code.
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#44I'm looking for a solution to filter large openapi specs to the most concise complete subset. I've implemented three different variations, two of which appear not to prune enough, and one of which appears to prune too much. Any recommendations?
Interesting, are you trying to automatically create and use components? Or only show certain fields?
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#45Earlier quoted context omitted.
Why are you looking for an alternative to Django Ninja? What about it is deficient for you? Curious because I am about to use it.
Not a technical reason: I've been using Django Ninja to medium/big app with lot of validation logic, and it was a delight. It was easy to start and integrates well with Django, but I'm moving away from it, not because I dislike it, I still like the approach and ergonomics. However, the project seems somewhat abandoned or at least struggling with updates (last release is in August 2024) and with lots of PRs staled. Th…
Hi mariocesar
Django ninja creator here
The project is used in a lot of critical infrastructure so we are prasing more about stability and performance rather then newest featers
On the other hand we prise all fork and keep an eye on them on the features that seems interesting
BTW next relrase is planned by the end of this month
Cheers
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#46I'm looking for a solution to filter large openapi specs to the most concise complete subset. I've implemented three different variations, two of which appear not to prune enough, and one of which appears to prune too much. Any recommendations?
Are you trying to prune inaccessible types or something? I'm not sure what you mean by concise complete subset, but in the past I had good success with custom rules in spectral [0]. [0] https://github.com/stoplightio/spectral
The task: I have a massive OpenAPI spec, and I want to drop all operations except for read-only ones. I want to preserve all referenced types, but slim the YAML as much as possible and remove extraneous elements.
I've tried prunes operations while preserving referenced components using redocly.
I've tried openapi-extract CLI to extract only components I reference.
And I've tried openapi-format CLI.
They all give different results, and I can't tell whether I am pruning too much or too little.
And yes I'm using spectral at the end, but it doesn't necessarily show it you're missing something that isn't referenced in the final output.
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#47Earlier quoted context omitted.
Not a technical reason: I've been using Django Ninja to medium/big app with lot of validation logic, and it was a delight. It was easy to start and integrates well with Django, but I'm moving away from it, not because I dislike it, I still like the approach and ergonomics. However, the project seems somewhat abandoned or at least struggling with updates (last release is in August 2024) and with lots of PRs staled. Th…
Hi mariocesar Django ninja creator here The project is used in a lot of critical infrastructure so we are prasing more about stability and performance rather then newest featers On the other hand we prise all fork and keep an eye on them on the features that seems interesting BTW next relrase is planned by the end of this month Cheers
Im really happy to hear from you and from Django Ninja!
First off, I just want to say how grateful I am for your work. I know how challenging it can be to maintain opensource projects, and I truly appreciate the effort
Wishing you all the best.
This is a bit unrelated, but something thats been on my mind, how are things for you with everything going on in Ukraine? I cant imagine how difficult it must be to deal with such situation while also staying active in open source
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#48Python async has been a big mess. I haven’t looked back since moving to a Go + GRPC + Protobuf stack. I would highly recommend it.
Love Go (and async python, for different reasons) but miss me with the gRPC unless you are building hardened internal large enterprise systems. We adopted it at a late stage startup for a microservices architecture, and the pain is immense.
So many issues with type duplication due to weird footguns around the generated types. Lots of places where we needed to essentially duplicate a model due to the generated types not allowing us to modify or copy parts of a generated type's value and so forth.
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#49Hey everyone! While working on a project that required OpenAPI docs across multiple frameworks, I got tired of maintaining separate solutions. I liked FastAPI’s clean and intuitive routing, so I built FastOpenAPI, bringing a similar approach to other Python frameworks (Flask, Sanic, Falcon, Starlette, etc). It's meant for developers who prefer FastAPI-style routing but need or want to use a different framework. The p…
[dead]
Re: Show HN: FastOpenAPI – automated docs for many Python frameworks
#50Every FastApi project I've worked on (more than a few) had an average of less than 1 concurrent request per process. The amount of engineering effort they put into debugging the absolute mess that is async python when it was easily the worst tool for the job is remarkable. If you don't know why it is hilarious that a FastApi project would have less than one concurrent request per process you shouldn't be making techn…
lol what. Did they not use an asgi server? Sounds like it was just misconfigured.
Honestly it is mostly caused by people from the machine learning end of the ecosystem not understanding how cooperative multitasking works and trying to bolt a web framework to their model.
That coupled with the relative immaturity of the python async ecosystem leads to lots of rough edges. Especially when they deploy these things into heavily abstracted cloud ecosystems like Kubernetes.
FastAPI also trys to help by making it "easy" to run sync code but that too is an abstraction that is not majorly documented and has limitations.