In my projects, I am regularly looking for a flexible and cost-effective backend with a NoSQL database. Cloud solutions like Firebase are popular but often either expensive or come with limitations. That’s why I decided to try Appwrite—an open-source backend that promises a powerful alternative to existing solutions.

At first glance, Appwrite seemed to offer exactly what I needed: a self-hosted platform with database functionality, user management, and an SDK for various programming languages. However, the more I used the official Appwrite SDK, the more I realized that it had some weaknesses that unnecessarily complicated my development work.

One of the most frustrating aspects was the strong focus on working with IDs. Many functions required constant passing of IDs instead of using a more intuitive, object-based structure. This quickly made the code cumbersome and error-prone. Additionally, I found the CRUD operations to be more complex and less elegant than I would have liked.

Since I was not aware of a satisfactory solution, I decided to write my own NPM package. My goal was to create an API that felt more natural by working with objects and significantly simplifying CRUD operations.

In this article, I want to share my first experiences with Appwrite, highlight the pros and cons of the official SDK, and explain why I developed my own NPM package.

Discovering Appwrite

While searching for an alternative to Firebase, I came across Appwrite via ChatGPT. What convinced me right away was the price-performance ratio: Appwrite offers many features of a modern backend platform—including a NoSQL database, user management, and storage—without high costs or dependency on a major cloud provider.

Currently, I am working on an event app and wanted to try an all-in-one solution that I could potentially host myself. Appwrite seemed perfect for this use case. The installation was surprisingly easy, and the intuitive web interface allowed me to set up the backend in no time. I was particularly impressed by how quickly I could create databases, collections, and users—without complicated configurations or hidden limitations.

The integration of different components also worked smoothly. Within minutes, I had a functional backend structure for my app and could start development immediately. However, while the first steps were very promising, I soon encountered some challenges, particularly when working with the official SDK.

Official Appwrite SDK - Pros and Cons

While setting up Appwrite via the web interface was highly intuitive, working with the official SDK turned out to be less pleasant. One issue that quickly stood out was the strong focus on working with IDs.

A simple example: To update a document, I had to pass not only the document ID but also the collection ID and database ID.

Of course, the official Appwrite SDK also has some advantages: It covers a wide range of functions, is available for various programming languages, and allows direct integration into existing projects. Nevertheless, I felt that the developer experience could be significantly improved with a more object-oriented approach and a simplified API.

This is precisely why I decided to develop my own NPM package to address these issues.

Introducing the @marcelkloubert/appwrite-sdk NPM Package

To address these challenges, I developed my own NPM package: @marcelkloubert/appwrite-sdk. This package builds on the official Appwrite SDK and extends it with an object-oriented API that makes working with Appwrite much easier.

Instead of constantly working with IDs, my package allows developers to work with objects such as Project, Database, Collection, Attribute, and Index. This results in a more natural and intuitive coding experience. For example:

import { AppwriteProject } from "@marcelkloubert/appwrite-sdk";

// Initialize the project and load all entities
const project = new AppwriteProject();
await project.init({ withDatabase: true });

// Access a specific database
const foo = project.databases.getDatabase("foo");

Through the “foo” database, you can retrieve a collection by name and, for example, add a new document:

interface BarCollectionDocument extends Model.Document {
  buzz: number;
  test: string | null;
}

// Retrieve the "bar" collection
const bar = foo.getCollection("bar").wrap<BarCollectionDocument>();

// Insert a new document
const newDoc = await bar.insertOne({ buzz: 42 });

Other operations are just as simple:

// Update a single document
const updatedDoc = await bar.updateOne(newDoc, { buzz: 666 });

// Delete a document
await bar.deleteOne(updatedDoc);

A key focus for me was also simplifying bulk operations:

const newDocs: BarCollectionDocument[] = [];

// Insert multiple elements
await bar.insert(({ document }) => {
  // This is a callback that is executed after a new document is added
  newDocs.push(document);
}, { buzz: 1 }, { buzz: 2 }, { buzz: 3 }, { buzz: 4 });

// Update multiple documents with filters
await bar.update({ test: "123" }, {
  queries: [Query.greaterThan("buzz", 1)],
});

// Delete multiple documents with filters
await bar.delete({
  queries: [Query.lessThan("buzz", 3)],
});

// Iterate through a collection with a cursor
const cursor = await bar.query();
for await (const document of cursor) {
  // ...
}

Conclusion and Outlook

For me, Appwrite has proven to be an exciting alternative to Firebase—especially due to its easy setup and attractive price-performance ratio. My initial experience with the platform was very promising, but in practice, the official SDK turned out to be cumbersome. The strong focus on working with IDs and the less intuitive API motivated me to develop a solution that makes using Appwrite easier.

With my own NPM package, I have attempted to solve these issues by providing an object-oriented API that simplifies CRUD operations and makes handling databases, collections, and attributes more natural. Early tests show that this approach not only improves code readability but also speeds up the development process.

But this is just the beginning. In the future, I want to further improve my package to offer even more convenience and flexibility when working with Appwrite. Potential enhancements could include advanced query mechanisms or deeper integration into existing frontend frameworks.