mr_Fatalyst

How I answered before, I started working on a router for DRF/Django integration, but Django's project structure made it surprisingly tricky to implement cleanly. I keep it in my mind.

Thanks!

Right now, explicitly specifying response_model is required, but only for documentation purposes. Python's type annotations alone aren't sufficient for reliable inference at runtime. I'm considering adding automatic inference support not only for models but also for basic types (like built-in primitives).

Currently, FastOpenAPI doesn't provide built-in support specifically for documenting streaming APIs. As far as I'm aware, support for streaming (chunked responses) in the OpenAPI specification itself is still limited.

Yes, Quart is supported.

The full list of frameworks is: Falcon, Flask, Quart, Sanic, Starlette, and Tornado.

Looks like I accidentally missed Quart in some parts of the docs—my bad, apologies! It’s included in the examples.

Glad you like the idea!

Actually, returning a Pydantic model directly isn't mandatory—it's just a recommended and convenient approach to ensure automatic data validation and documentation.

If you prefer, you can keep your existing route handlers as-is, returning dictionaries or other JSON-serializable objects. FastOpenAPI will handle these just fine. But using Pydantic models provides type safety and cleaner docs out of the box.

You're right, I'm mostly maintaining different private APIs. In that context, optimizing for individual developer velocity definitely makes code-first more appealing. But you're spot-on about larger orgs and standards—spec-first can simplify collaboration and consistency in those scenarios.

Thanks! I personally prefer code-first because it aligns well with Python’s dynamic nature and feels more natural in daily coding. Spec-first definitely has advantages (especially clarity and collaboration), but it can sometimes introduce friction, especially when rapidly iterating on APIs.

I think the popularity of code-first tools (like FastAPI) mostly comes from the convenience of quickly defining and changing APIs right alongside your code.

I actually started working on a router for DRF/Django integration, but Django's project structure made it surprisingly tricky to implement cleanly. It's still on my list though.

Sometimes you simply can't switch frameworks—due to legacy code, project constraints, or team preferences. FastOpenAPI is specifically designed for situations like these: it provides FastAPI-style routing and automated OpenAPI docs without forcing you to change the underlying framework.

P.S. I'd prefer FastAPI as well ;)

In the examples, I used prefixes to demonstrate API versioning, but you're not limited to this approach. Prefixes can be used for general route structuring as well (like grouping entities, etc.), not just for versioning.

Personally, I prefer using router composition for flexible route organization. You can see a clear example of this with Flask here: https://github.com/mr-fatalyst/fastopenapi/tree/master/examp...

In this example, routes are split into routers by entities, which are then grouped into an api_v1 router, and finally, this api_v1 router is added to the main router.

Thanks a lot! Glad to hear it fits your needs.

For a clean, documentation UI, the best open-source options right now are probably Swagger UI and ReDoc. FastOpenAPI uses both by default:

- Swagger UI: interactive, lets you try out endpoints live. - ReDoc: more minimalist and professional-looking but static.

If you're looking for something different, you might check out RapiDoc, which is also open-source, modern, customizable, and supports interactive API exploration.

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!