Idea: Make SDK asynchronous.

[Niraj-Kamdar]

We can optimize the performance of the SDK by making it compatible to run in an asynchronous manner.
I have a few ideas about where to start. If this aligns with your current goal then I would be happy to contribute.

[eldadfux]

Would be great if you could share your design idea in more detail, and what changes should be taken to make this feature possible.

[Niraj-Kamdar]

We can use aiohttp instead of requests to make client module async. By doing this we can make call method an awaitable coroutine and this will propagate all the way up to other classes like Database, Health, etc, and make it asynchronous.

What will be the benefits?
Users can start multiple requests concurrently.
Ex:

db = Database()
await db.create_collection(...) # req1
await db.create_collection(...) # req2

Here, both req1 and req2 will run concurrently instead of sequentially.

[eldadfux]

@Niraj-Kamdar is there a way to make call method an awaitable natively without using any 3rd party dependency? Also what about backward compatibility after this change?

[Niraj-Kamdar]

Yes, we can make call method an awaitable by running it in threadpool but this solution has a con - by default, it will only run 5 tasks concurrently while native asynchronous library like aiohttp can run many tasks concurrently and all tasks run co-operatively instead of pre-emptively. For example, if I spawn 10 tasks concurrently when the underlying method is running on threads it will only run 5 tasks at a time, and when they complete it will start the remaining 5 tasks. In the case of the native async library like aiohttp, all tasks will spawn concurrently.

I believe concurrency is important to scale application but some people may still want a normal synchronous version of SDK maybe because their application hasn't designed to run concurrently. So, for backward compatibility, we have to consider the following options:

• Create a separate async SDK.
• Create async methods with "a" prefix in the same SDK. For example: call will be acall. Cpython has done this with __enter__ and __exit__ methods and they call it __aenter__ and __aexit__ when used asynchronously.

[lohanidamodar]

@christyjacob4 is this relevant? Please close if not.

[notpushkin]

Just my 5¢: might want to look into https://www.python-httpx.org/, which supports both sync and async, while still retaining Requests-like API. Not sure if it would be possible to not duplicate the wrapper, but at least it will be one external dependency vs two (requests + aiohttp).

[christyjacob4]

@notpushkin is this something you'd like to explore ?

[eitozx]

This issue was opened 2 years ago & still not implemented. I highly support @Niraj-Kamdar 's idea. Please let us know if this is in the plan. And I would love to contribute if need any help.

[stnguyen90]

Latest PR on this: appwrite/sdk-generator#453

[viv1]

The above PR never made it. In this age, Python SDK absolutely should have asynchronous support. This will make a big difference to network bound calls, which happens to be a common case due to a lot of microservice/microcontainer type of apps these days.

[Humarr]

🚀 From Problem to Solution: The Birth of async_appwrite, the Asynchronous Appwrite SDK 🐍

- It Started with a Simple Problem…

Imagine this: You’re a Python developer, knee-deep in building an innovative web application. You’ve chosen Appwrite as your backend because of its versatility and power. Everything’s moving along smoothly—until it’s not.

You start noticing bottlenecks. Your APIs are not as responsive as you’d like. Despite all the optimization tricks up your sleeve, the app isn’t scaling the way it should. Frustrated, you dig deeper and realize the culprit: synchronous API calls are slowing everything down.

There must be a better way.

• The Lightbulb Moment 💡

That’s exactly the situation I found myself in, juggling FastAPI and Appwrite. I needed asynchronous interactions to make my application more efficient, but the official Appwrite SDK didn’t support async operations out of the box.

So, I started coding. I created custom classes, overriding the existing ones to make them async using httpx and asyncio where necessary. What started as a quick fix for my project soon evolved into a robust solution that transformed how my APIs interacted with Appwrite.

• From a Personal Solution to a Community Asset

As I refined my code, I realized this wasn’t just my problem—it was likely a pain point for countless other developers working with Python, FastAPI (or any asynchronous code), and Appwrite. Why should we all have to reinvent the wheel?

That’s when the idea hit me: Why not share this with the community? Why not create a tool that makes asynchronous programming with Appwrite accessible and easy for everyone?

• Introducing the Asynchronous Appwrite SDK for Python!

🔥 Designed for Developers, by a Developer: This SDK is built to make your life easier. If you’re using FastAPI or any other async framework, it seamlessly integrates, turning your Appwrite interactions into fast, non-blocking operations.

🚀 Boost Your App’s Performance: With async capabilities, your API can handle more concurrent requests, improve response times, and offer a better user experience.

💡 Simple, Efficient, and Powerful: No need to write complex workarounds or duplicate code across projects. This SDK handles everything for you, out of the box.

• Why Should You Care?

• Better User Experience: Faster response times mean happier users.

• Scalability: Handle more requests without needing more resources.

• Future-Proof: Asynchronous programming is the way forward. Stay ahead of the curve.

Ready to Experience the Difference?

I built this SDK to solve my problem, and now I’m sharing it to help you solve yours. If you're building modern Python applications, this is the tool you've been waiting for.

👉 [Try the Asynchronous Appwrite SDK on PyPI Now] (https://pypi.org/project/async-appwrite/)

👉 [Check out the GitHub Repository] (https://github.com/humarr/async-appwrite)

[Humarr]

The above PR never made it. In this age, Python SDK absolutely should have asynchronous support. This will make a big difference to network bound calls, which happens to be a common case due to a lot of microservice/microcontainer type of apps these days.

Check out async-appwrite on pypi