71–80 of 85 posts
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?
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).
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 p…
[dead]
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.
I do the opposite and leave generating openapi docs to an LLM. Mostly that just involves spelling out the obvious; so it's not a particularly hard job for an LLM. The code is the full specification of what a thing does. Anything else is just a watered down version of the thing. In architecture terms, there is no blue print for the blue print, typically. This is a fundamental misconception some people have about softw…
If you just need docs then maybe that works for you. OpenAPI can do so much more though - it can specify a protocol.
If you can't see why a protocol specification is different from an implementation of that protocol then I don't know what to tell you.
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.
Just to drop another two cents in here - I feel like code-first is great when it's a solo project or very experimental, but when you're working on a larger team, or more to the point, working with other teams, spec-first is invaluable. You can publish a working spec long before worrying about any sort of technical implementation, which means you can get feedback from the other teams involved, which can save an immens…
I still want to build something that can handle protocol evolution and also do protocol up/down migration on the response (like the stripe API team has done).
Earlier quoted context omitted.
Does the flask extra also support quart?
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.
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
> 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.
Earlier quoted context omitted.
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.
Why no Django?
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