🚀 Feature: Improve API syntax

[superakabo]

🔖 Feature description

The APIs for Appwrite can be improved, made less verbose and more Dart/Flutter friendly by adopting a declarative approach in many scenarios. Also, since majority of Appwriters might have experience with Firebase, I think it will be best to create similar APIs or better. I think the experience will be better if developers for example, do not have to create instances of Client, Users, Database, Storage etc. objects first.

🎤 Pitch

Instead of

Client client = Client();
client
    .setEndpoint('https://localhost/v1') // Your Appwrite Endpoint
    .setProject('5e8cf4f46b5e8') // Your project ID
    .setSelfSigned(); // Use only on dev mode with a self-signed SSL cert

It can be

Appwrite.instance.initialize(
   endpoint: 'https://localhost/v1',
   propjectId:'5e8cf4f46b5e8',
   selfSigned: true,
);

Instead of

Users users = Users(client);
Future result = users.create(
    userId: '[USER_ID]',
    email: 'me@appwrite.io',
    password: 'password',
    name: 'My Name'
 );

It can be

Appwrite.instance.createUser(
    userId: '[USER_ID]',
    email: 'me@appwrite.io',
    password: 'password',
    name: 'My Name'
);

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[dancamdev]

I completely agree with your first example, the one related to the Client. It is not idiomatic when it comes to Dart/Flutter and especially if compared with firebase's

await Firebase.initializeApp()

I'd change the Client initialization into being something like this:

Client.instance.initialize(
    endPoint: 'https://localhost/v1',
    projectId: '<whatever>',
    selfSigned: true,
  );

Reading your second suggestion, it looks like you'd want to have all the features, such as Client, Users, Database, Realtime and so on, under the same, global, AppWrite instance.

Although I see the conveniency of it in LOC terms, I think it comes with a compromise in terms of clarity.

Plus, if needed, it looks to me as if an extension is all you need to get the Client.instance.createUser API.

[superakabo]

Hi @dancamdev,
Yes. It will be great to have all features under a single AppWrite instance. I believe it will reduce the learning curve for anyone familiar with Firebase.

Manually creating an extension to cater for this will be inconvenient and unproductive for most developers. Also, not all developers will have the skills to implement it correctly.

[dancamdev]

Although Firebase doesn't have it under the same instance, matter of fact Firebase goes the very opposite route, by having different packages for each of their features.

Let's see what others think, In general, I'm big into libraries being unopinionated in these cases, so that anyone can implement what fits their project best.

[superakabo]

Okay

[stnguyen90]

In general, I'm big into libraries being unopinionated in these cases, so that anyone can implement what fits their project best.

This is one of the biggest reasons why we prefer not to change to a singleton pattern. With a singleton, you wouldn't be able to create multiple instances of a Client if you need it. For example, in Dart, you could have 1 Client that is authenticated using an API Key for admin operations and another with a JWT token for operations on behalf of a user.

[superakabo]

Hi @stnguyen90,

Appwrite already has the client and server sdk for such scenarios. I believe any implementation that does not require the user to create instances of the Client or pass them as parameters in order to use Appwrite’s features will be better.

[lohanidamodar]

Personally for me I'm good with the client approach, if I need I can create my own singleton client. However having client, I can even work with multiple projects on a single application if needed. It gives much more flexibility and also it keeps consistent with other SDKs.

[Vedsaga]

I guess we should not changes, as @lohanidamodar pointed very correctly. Completely agree