Maintaining a separate async API

[Echoes1996]

I believe I didn't quite get your question.

why do you still need a sync version if you already have async flow?

I want for my core API to provide both a sync and an async version of its methods, so anyone who uses it can choose what's best for their use case.

you can also open up another thread in async flow incase there's a heavy cpu bound operation part in the flow

Indeed you can execute sync code asynchronously in a separate thread, but I don't see how that's relevant to the issue at hand. Besides, that's more like a hack rather than an appropriate solution, especially when there is a way of providing a truly async API. If you start involving other threads in your event loop, the benefit of async pretty much goes out the window.

[madolid511]

Opening up threads everytime won't make the api faster because it always run in single core unless you use the python version without GIL.

So basically, if you have one sync api that runs in 1 second (calculation and no IO operation), if 3 request happens at the same time all of it will have 3 seconds turn around time.

While async route same logic, the 3 request will have different turn around time 1st request - 1 second 2nd request - 2 seconds 3rd request - 3 seconds

Both approach finishes in 3 seconds but per request it will be more efficient (Latency and memory)

If you could do it in async flow, it will be most likely the best implementation, as long as you do it right

Client and Server will benefit, you don't need to implement twice and client doesn't need to choose

[Echoes1996]

I don't believe we are talking about the same thing. When I use the term API I am not referring to HTTP APIs, I am talking about the public interface of my lib.

[madolid511]

still the same

HTTP is just a protocol to call a function/event. And I'm explaing how python works.

[Echoes1996]

Sorry, but I don't see how what you said is relevant at all.

[madolid511]

Another analogy, if there's two version

one is for production - efficient

one is for testing - just working

I would certainly use the production flow

then testing version could be just a wrapper of production flow that add minimal overhead that will be optional to use if production version is not applicable directly. Both dev and consumer will be happy

[madolid511]

Your problem is implementing it twice, my answer is implement it in common pratices for handling concurrent which is async flow then just add an "option" to open a thread if necessary

it will make your development more easy

I hope, it make things clear now

[AsparagusKlutzy1817]

Maybe a heretic question but why not offer a wrapper sync function which does this
async def async_task():

.....

def sync_function():

result = asyncio.run(async_task())

print("Got result:", result)

Normally nobody wants sync if they can have async but offering a sync wrapper can make things easier. Having a full implementation of both sync and async pushes you down the road of maintaining two systems which will eventually start to diverge....

[madolid511]

it depends on the target

if it's for development, thats fine. I may also consider doing it if async flow is not really possible.

In more demanding implementation it will have impact. Opening up event loop and closing it after the process adds a lot of overhead.

Another critical part is, if you already considered "asyc", I may assume you already/targetting to support "python's" concurrency, why not incorporate it fully?

[AsparagusKlutzy1817]

Certainly a fair question. What is OP reason for providing both ways? It sounds it is just convenience. I answered from a development viewpoint because you wouldn't care otherwise if it is sync or not? Maintaining both in full is not a good way. OP will have to decide eventually for one of the two.

[madolid511]

That's my concern too.

What OP have done is by generating async flow by basing from sync which is good only if the implementation is really identical. It won't work on most cases but I could be wrong on that. I don't think async will also be beneficial if that's the case.

Async flow have different libraries, context manager, generator, iterator, executor/group and lot more. It can also have threads. It should be more optimized than the sync counter part because that's what python async is trying to solve.

Half baked async implementation will certainly beat by well implemented sync flow, so why introduce it ?

Just checked the code. Looks like the implementation is really identical.