Show HN: FastOpenAPI – automated docs for many Python frameworks

github.com

153 points by mr_Fatalyst a month ago


mr_Fatalyst - a month ago

Hey 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 project is still evolving, and I’d love any feedback or testing from the community!

wg0 - a month ago

After 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

ltbarcly3 - a month ago

Every 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 technical decisions.

memset - a month ago

This is really cool - something I've been looking for with Flask. Cleanest implementation with just the decorator that I've seen.

(As an aside, is there an open-source UI for docs that actually looks good - professional quality, or even lets you try out endpoints? All of the decent ones are proprietary nowadays.)

These335 - a month ago

Love Flask, but this has always been a missing tool. I have a question though - it seems like you're actually modifying the response data type for Flask routes so that it's a Pydantic model. Is that an optional approach? While I wish that were the official standard, if it is not optional then I think that's quite a big ask for maintainers of existing APIs who want to use your docs library. Regardless, I'm looking forward to trying it out! Looks great.

odie5533 - a month ago

Awesome project! It looks so seamless for Flask! Just switch routers, and you model deserialization/serialization, and /docs. Really impressive work!

Is there any way to not need the response_model= and instead infer from return type?

s3rius - a month ago

That's really neat! I made a project for fastapi-like dependency injection for AioHTTP and it also has OpenAPI spec generation. If I could, I would like to use your library for specs instead of self-written solution.

Here's my project repo: https://github.com/taskiq-python/aiohttp-deps

gister123 - a month ago

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.

mr_Fatalyst - a month ago

Big thanks to everyone for the feedback and your reactions! I've started working on version 0.5.0 and will try to include as much as possible of what was highlighted here.

bravura - a month ago

I'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?

Everdred2dx - a month ago

Nice. This was one of the main shortcomings in Falcon that pushed me to switch some projects to FastAPI. That said FastAPI had many other benefits that went far beyond API specs.

dtkav - a month ago

Nice work! What's your take on spec-first vs. code-first?

I'm a fan of spec-first (i worked on connexion), but I've noticed that code-first seems to be more popular.

Onavo - a month ago

No love for Django? I am looking for an alternative to DRF and Django-ninja that can optionally generate typed APIs and docs directly from the model definitions.

BerislavLopac - a month ago

I'm honestly disappointed how OpenAPI keeps being used over and over as documentation, and extremely rarely as what it excels at, which is specification.

We build all kinds of frameworks with routing and request/response validation, and then extract that into OpenAPI format, ofteng having to jump through hoops to adapt our internal data types and structures into those supported by JSON Schema. Instead, we could be doing the opposite: writing the OpenAPI spec first, and use tooling to make routing and validation based on it in an automated way. That has been done before [0] [1], but we're still just scratching the surface of what is possible.

Yes, I am aware that it's not easy to manually write the specs using JSON or even YAML, but we need a better focus on tooling around it; currently only Stoplight [2] gives a solid level of support in that area.

[0] https://connexion.readthedocs.io

[1] https://pyapi-server.readthedocs.io/

[2] https://stoplight.io/

zapnuk - a month ago

Why not just use fastAPI and have it built into the framework?

JodieBenitez - a month ago

No Bottle ?

adhamsalama - a month ago

Cool!

curtisszmania - a month ago

[dead]

samstave - a month ago

[dead]

Sodosorry - a month ago

[flagged]

blahhh2525 - a month ago

[flagged]

wseqyrku - a month ago

I like this. I think genai could be used to fill in gaps in, for example, Wikipedia with a note that it's AI generated. If anything I think that's a good starting point.