Repository navigation
Support for Asynchronous Environments? #12
Description
Description
This is more of a question/enhanchement! Does typesense-python have support for asynchronous environments?
By this I mean:
- Are functions that change search indices (save/delete objects, creating/deleting a new index) blocking?
- Algolia is synchronous "by design" and many index functions place tasks into a queue to be processed - does Typesense do something similar?
Activity
kishorenc commentedon Jul 12, 2021
@dhrumilp15 Typesense backend API is synchronous in nature. For a large number of use cases this is more convenient as you get to know the result of an operation immediately, instead of having to make one more API call to look up the status.
The Python client is also synchronous, so when you call a method on the client, it will block until the response arrives or the operation times out.
Can you please help me understand how asynchronous operations will be helpful to your use case? That will help us prioritize future work.
vd2org commentedon Jul 17, 2021
This does not mean that the API itself has to be asynchronous. This means support for asyncio for using the api in asynchronous applications like FastAPI.
vd2org commentedon Jul 17, 2021
You can take a look at my async library for CouchDB, which is designed in much the same way as yours, but for an async environment:
https://github.com/vd2org/wheelchair
haoyun commentedon Dec 24, 2021
I found a project https://github.com/devtud/aio_typesense that does the job.
i hope, howevr,
async/awaitwill be officially supported intypesens-python.trollfot commentedon Dec 19, 2023
I am poking a dead horse, here, but I started my own implementation, based on aio_typesense that I updated and heavily modified.
https://github.com/trollfot/typesense_aio
Feel free to jump in
mgraczyk commentedon Feb 7, 2024
I forked to add async in such a way that it will be easy for me to keep the fork up to date:
https://github.com/Quilt-AI/typesense-python
This doesn't require many changes to the current codebase. Supporting both at the same time would be slightly more annoying/complicated but definitely doable.
Others are welcome to fork or use it. I think
httpxoraiohttplike I have done is the way to go.joel-odlund commentedon Jan 14, 2025
Another vote to implement async officially.
We are currently running 3 instances with 100 workers each. On the client side, we one instance that performs multiple searches concurrently. We have to configure FastAPI to be synchronous in order to accommodate Typesense, and we are considering an unofficial async client, which is unfortunate.
I think the need for async becomes apparent when using an external embedding service. We are waiting for up to a second for the embedding call. When we have a lot of queries, we need parallelism to get reasonable performance. An async client would be the most natural to use here.
jensimik commentedon Apr 16, 2025
also missing that the http part of the client could be async
running in an async environment then it is a must