61–70 of 85 posts
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
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.
I really enjoy Python's asyncio. I'm a big fan of aiohttp and the entire aio* ecosystem. Then there's Rust's Tokio for the things that need performance.
Two big deals of Trio and AnyIO are channels (similar to Go's channels), the ability to return data from starting a task in a nursery/task group:
async def my_consumer(task_status = anyio.TASK_STATUS_IGNORED):
tx, rx = anyio.create_memory_object_stream()
task_status.started(tx)
async for message in rx:
...
async def my_producer(tx):
await tx.send("hello")
await tx.send("world")
await tx.aclose()
async def main():
async with anyio.create_task_group() as tg:
tx = await tg.start(my_consumer)
tg.start_soon(my_producer, tx)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.)
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?
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.
Earlier quoted context omitted.
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.
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 merg…
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.
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 software design vs. traditional engineering/architecture.
When designing buildings, you put all your effort in the blue print. And then you build it. With software, you put all your effort in the blue print (i.e. the source code). And then you run/compile it. In neither case is it valuable to have a meta blue print. At best you might do some sketching, prototyping, modeling. But these are activities intended to learn, not to document. 3D printing makes the metaphor more obvious maybe. Because it makes engineering more similar to software development. All the key work is digital.
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
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.
Is there any way to not need the response_model= and instead infer from return type?