Live data from Hacker News

Show HN: FastOpenAPI – automated docs for many Python frameworks

github.com

51–60 of 85 posts

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#51

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…

In what context do you need to maintain multiple frameworks?

My use case for fastAPI is very specific (we only maintain APIs for ML models), so I'm curious to learn about this.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#52
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.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#53
post #31

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 techn…

That’s completely off topic, and it says more about the team than the tool.

The topic is generating documentation for FastApi API's right? If someone came and said "here's a great way to prevent over-spray when painting your dog" I think it would be reasonable to take one small step back and just explain that painting your dog is a bad idea.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#54
post #30

Earlier quoted context omitted.

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…

Everything you say here is true, but if you do an analysis and run benchmarks on non-toy projects you'll quickly find that async Python is a bad choice in virtually every use case. Even for use cases that are extremely IO bound and use almost no compute async python ends up dramatically increasing the variance in your response times and lowering your overall throughput. If you give me an async python solution, I will bet you whatever you want that I can reimplement it using threads, reduce LOC, make it far more debugabble and readable, make it far easier to reason about what the consequences of a given change are for response times, make it resistant to small, seemingly inconsequential code changes causing dramatic, disastrous consequences when deployed, etc etc etc. Plus you won't have a stupid coloring problem with two copies of every function. No more spending entire days trying to figure out why some callback never runs or why it fires twice. Async python is only for people who don't know what they are doing and therefore can't realize how bad their solution is performing, how much more effort they are spending building and debugging vs how much they should have to put into it, and how poorly it performs vs how it could perform.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#55

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 for…

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.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#56

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…

Does the flask extra also support quart?

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#57

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…

Does the flask extra also support quart?

And would it document a streaming API? (With transfer-encoding: chunked) The support for that in OpenAPI is still in progress, I believe.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#58
post #31

Earlier quoted context omitted.

That’s completely off topic, and it says more about the team than the tool.

The topic is generating documentation for FastApi API's right? If someone came and said "here's a great way to prevent over-spray when painting your dog" I think it would be reasonable to take one small step back and just explain that painting your dog is a bad idea.

The first line of the linked page says otherwise:

> FastOpenAPI is a library for generating and integrating OpenAPI schemas using Pydantic v2 and various frameworks (Falcon, Flask, Sanic, Starlette, Tornado).

And, no, the analogy to painting dogs isn’t valid. I’m sure you’re right to say that the projects you worked on did not end well but that single anecdote doesn’t invalidate all of the other projects which didn’t have that problem, much less the desire other people might want for a similarly-easy experience when using different frameworks.

Re: Show HN: FastOpenAPI – automated docs for many Python frameworks

#59
post #5

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

Because not everyone wants to be a part of the asyncio trend.

Asyncio in Python is a poor feature that splits the language's ecosystem into 2 mutually-incompatible worlds, something Python only gets away with because it's too big to fail.

Meanwhile we've had Gevent for decades now. It gives us async that you can forget you have. Because rather than making code async, it makes the VM async.

Gevent could have been merged into CPython, but they chose explicit "structured concurrency" and the rest is history. History of sometimes moving forward and sometimes straying from the path and getting lost.

And lost Python's asyncio is. PDB, which lots of other debuggers base on, is still broken (cannot use await). The ecosystem? IPython uses asyncio internally so it cannot easily be embedded in a working async program. The only embeddable REPL I was able to find is this: https://github.com/prompt-toolkit/ptpython/blob/master/examp...... actually, it looks like someone is working on adding `await` support to PDB now, years after asyncio's first release.

Overall, lots of churn to get something (maybe) as good as Gevent, which we had in Python 2.7, or even before.

If a similar amount of effort was spent on first-class support for code hot-reloading and live program inspection, we would get a massive boost of productivity. But somehow even otherwise bright people choose to reimplement working solutions into something objectively worse, meanwhile our development/debugging loop still emulates loading punchcards into mainframes.

Post reply on HN