Isomorphic SDK

[ryanhlewis]

As of writing this, the AppWrite SDK is split between Server and Client configurations, as shown below.

Naturally, at first glance, there must be a striking difference between the two!

There isn't.

Considerations

There are three simple differences between the two: Accounts, Health, and Users.
For the other files in the SDK, 8/11 (72%) are identical.

Usually in Server-Side SDK configurations, as per Client Side vs Server Side SDK, the Server SDK is deliberately made to receive more data, as well as provide for more unsafe functions. This is not the case in AppWrite, where the same data is used for both Client and Server, as well as a majority of the same functions.

As for the current configuration, the entire Project seems to assume that only Clients exist upon Flutter and Web-based sources, while Servers exist in other languages. What about Unity games, written in both C# and JS? What about Android applications, developed within Java and Kotlin? What about Python clients, such as a marketplace? Taken to a natural endpoint, the current solution will provide two separate SDKs for each language: i.e. a JavaScript Client SDK and a JavaScript Server SDK.

Conclusion

Seeing how they are already mostly the same, I do not see any reason as to why it is not simply an All-In-One SDK.
They are literally one or two files different from one another.

Rebuttals

As for any concerns, let me see if I can address them early:

That would be unsafe! What a terrible idea! (Security)

Coding itself is taking a sword to a sandwich. There are plentiful ways to make it "safer", but setting up a confusing and difficult differentiated SDK system certainly only serves as a deterrent. If one uses an API Key in his Client software, by God, that is the fault of the programmer. The people who work with AppWrite MUST understand basic principles of computer ethicality and safe principles before they begin to program support for databases, user authentication, and more sensitive information.

They do different things. That is why they are separate. (Logic)

If only. They are exactly the same, save for literally one or two files. If this were a situation with blatantly different circumstances, such as Apples to Oranges, I would never consider pushing them together, but this is a situation between an existing SDK that is almost identical to its counterpart. It would save time, avoid confusion, and make this a much more scalable and friendly Project.
(Want to use the AppWrite SDK? Just import this one file!)

That would place unnecessary data on the Client, and unnecessary data on the Server! (Size)

All in all, the addition of Account to the Server SDK would cause a 14.7 kb increase, and the addition of Health and Users to the Client SDK would cause an 11.28 kb increase. In essence, around 15 kb keeps these SDKs seperate. While this number is small, it is actually not even real when it comes to compilation time, as code stripping will remove all unused code.
(And if you do not use code stripping, are you even serious about programming?)

[eldadfux]

Hey @ryanhlewis, and thanks for starting this discussion. This is a very painful point for Appwrite maintainers in the short life of the projects. Just for a brief history review, I will mention that we did start the project with the all-in-one approach but changed it lately, and we're still actively looking for the best balance between the two (or one 😉).

A few reasons why we currently have split versions of the SDKs:

• Security - yes, we don't want to see people pass an API key from a client integration, and we did see a few cases like that, but I agree this should not be our main concern.
• Users vs. Account - This is a hard one. It was challenging for us to explain the difference between the two services when the project first started. We saw many devs trying to perform actions on behalf of the user using an API key that doesn't work, and the same for trying to fetch a list of users from the client-side just to be disappointed when they figure we don't think it's a safe operation.
  Besides that, more actions are solely available to servers like collections management and storage buckets (soon). Splitting the SDKs seemed to make life easier for both maintainers and devs.
• Auto-Generator We use the auto-generator to build all the Appwrite SDKs using our Open-API spec file. The cost of maintaining almost similar SDKs is not significant for us.

With upcoming JWT support, more client-only routes will be available from the server API. We will be adding dedicated sections to the docs on how to authenticate these endpoints (API Key vs. JWT) + add better 401 errors to hint at a wrong usage of auth method.

This comment does not aim to say one approach is better than the other but rather to share the history and reasoning behind the current project status. We are very open to the community's opinions about this issue. We would welcome to adopt and solutions that could address best the majority of Appwrite use-cases and devs requirements.