mr_Fatalyst

7 ms·

1. 31.▲
   by mr_Fatalyst 2y ago

   Thanks! I have a draft for aiohttp integration. I think I'll add it later.
2. 32.▲
   by mr_Fatalyst 2y ago

   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.
3. 33.▲
   by mr_Fatalyst 2y ago

   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 i
4. 34.▲
   by mr_Fatalyst 2y ago

   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.
5. 35.▲
   by mr_Fatalyst 2y ago

   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.
6. 36.▲
   by mr_Fatalyst 2y ago

   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
7. 37.▲
   by mr_Fatalyst 2y ago

   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-fi
8. 38.▲
   by mr_Fatalyst 2y ago

   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 f
9. 39.▲
   by mr_Fatalyst 2y ago

   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.
10. 40.▲
    by mr_Fatalyst 2y ago

    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 wit
11. 41.▲
    by mr_Fatalyst 2y ago

    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
12. 42.▲
    by mr_Fatalyst 2y ago

    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
13. 43.▲
    by mr_Fatalyst 2y 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 approac
14. 44.▲
    Show HN: FastOpenAPI – automated docs for many Python frameworks(github.com)

    153 points by mr_Fatalyst 2y ago|77 comments