think-async VS arq

Lately, at my workplace, I've been doing a lot of asynchronous I/O programming in Python. In my case, ironically, I picked up Golang faster than Python's async paradigm despite Python being my primary language. Coroutine chauffeured asynchronous programming demanded a substantial shift in the way I used to compose solutions in synchronous Python.

However, after successfully writing two services using asyncio, SQS, DynamoDB, and aiobotocore—I'm convinced that this is actually worth it. Here're a few resources that I've found helpful along the way. Pull requests are very much welcome.

https://github.com/rednafi/think-async

I need to process a lot of long running IO heavy jobs with background workers. I've been using ARQ for a while but decided to take a crack at writing my own distributed queue.

Lately I've been writing asynchronous python code and yes, the resource integration problem has come again. Because now from version 1.4 SQLAlchemy has become asynchronous a new boilerplate was created. Now, as a scheduler, I took a completely asynchronous Arq. Considering the specifics of the service, long I/O operations, it seems that the service turned out to be more optimal in asynchronous execution. I haven't measured the performance yet, but I think I'll write another post about it.