-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🚀 Feature: Improve API syntax #94
Comments
I completely agree with your first example, the one related to the 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 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 |
Hi @dancamdev, 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. |
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. |
Okay |
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. |
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. |
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. |
I guess we should not changes, as @lohanidamodar pointed very correctly. Completely agree |
🔖 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
It can be
Instead of
It can be
👀 Have you spent some time to check if this issue has been raised before?
🏢 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: