Idea: Make SDK asynchronous.

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.

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

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.

@Niraj-Kamdar

@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?

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.

@christyjacob4

@christyjacob4 is this relevant? Please close if not.

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).

@notpushkin

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

@Niraj-Kamdar

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.

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

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.

🚀 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)

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

are there any plans for appwrite to officially support async?

are there any plans for appwrite to officially support async?

You can use async_appwrite. That way, you get the asynchronous capabilities while still holding on to the value of the Appwrite SDK itself.

Check it out on PyPI, and see if it's what you'd like to use.

And I'm quite sure you'd like it.

Cheers. A win for the python community

Please provide official support for async.

Sequential requests vs parallel requests - This metric makes appwrite lose in python community.

You can use httpx for asnyc calls. It supports asyncio and trio

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

Idea: Make SDK asynchronous. #26

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Sunbelt Computer Software

PL/B Language Development and Support

Idea: Make SDK asynchronous. #26

Description

Activity

eldadfux commented on Oct 3, 2020

Niraj-Kamdar commented on Oct 4, 2020

eldadfux commented on Oct 4, 2020

Niraj-Kamdar commented on Oct 5, 2020

lohanidamodar commented on Feb 11, 2022

notpushkin commented on Apr 11, 2022

christyjacob4 commented on Apr 12, 2022

eitozx commented on Sep 27, 2022

stnguyen90 commented on Apr 28, 2023

viv1 commented on Aug 13, 2024

Humarr commented on Sep 11, 2024

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

Humarr commented on Sep 11, 2024

s4093120 commented on Dec 5, 2024

Humarr commented on Feb 3, 2025

chaitanyavaddi commented on May 26, 2025

leon1995 commented on Aug 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions