🚀 Feature: Unify Dart and Flutter Package

[Mabenan]

🔖 Feature description

At the moment we have different SDKs for Backend (Dart) and Frontend (Flutter). This is not optimal for people who want to reduce their boilerplate code.

For example if someone want to use the same strongly typed data models in functions like he does in the frontend he is forced to write a lot of Boilerplate code to first generalize the API calls in a Package and then again define specific for the appwrite packages in a Server Package and Client Package again.

🎤 Pitch

My Idea is to create a Dart SDK booth used by Dart and Flutter and then one Specific Flutter SDK which is only used by Flutter.

In the specific Flutter framework only things like OAuth or other Frontend Specific things are defined.

This can be done b using Mixins in the Flutter SDK.

👀 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

[stnguyen90]

Thanks for raising this issue! 🙏🏼

For example if someone want to use the same strongly typed data models in functions like he does in the frontend he is forced to write a lot of Boilerplate code to first generalize the API calls in a Package and then again define specific for the appwrite packages in a Server Package and Client Package again.

Can you expand more on the boilerplate?

[Mabenan]

I created abstract API class which has basically the same methods like database,account,team and so on.

Then I have a singelton Class which holds an instance of the API that is given over an Init method.

In Server functions I created an Implementation of the API class that uses dart_appwrite package

In Client code I created an Implementation of the API class that uses appwrite package

[eldadfux]

We did this split for a few reasons:

1. A lot of the server or client method don't work in the opposite environment and no way for someone to understand that just like that no matter how familiar they are with Appwrite

2. Using an API key for authentication on the client is very dangerous. In the past we had the web SDK including both functionalities and we saw a lot of developers passing an API key on the client side, this is very risky.