Add Preference at the time of Account Creation

[punitdiwan]

I would like to suggest the addition of preference in the Account POST API while creating user Accounts. It avoids invoking two APIs from the client Side. if the preference is known beforehand, it can be added at the time of User Account Creation. However, the Preference payload should be an optional object.

[eldadfux]

It's always hard to decide when to couple request and when to not. So far we mainly tried to have consistency across APIs, sometimes unsuccessfully. If we do consider something like this, I think it should be a philosophical decision about what our approach is and why and how it affects all other REST APIs.

I don't think 1 API call vs 2 is a good enough argument for deciding on this change.

[Meldiron]

I personally agree with Eldad on this. Looking at other services such as Database or Storage, I can see similar behavior:

• 2 requests to fetch data from 2 collections
• 2 requests to create file, and set its ID in the collection document
• 2 requests to get 2 different queries results

I see these examples as micro-optim, just like I would see request&response modification or using short IDs for collections to make requests smaller.

---

On the other hand, I see these options in Appwrite:

• 1 request to create function deployment AND activate it
• 1 request to execute function AND get a response

I believe both of these came from the same problem - having to fire multiple requests. But in these examples, it is a bit more extreme, as you would need to keep firing many requests until one says the status of build/execution is finished. Also, considering the amount of code necessary for implementation, these two need like 10-liner to implement a recursive method.

For same reason I would consider these as possible feature requests:

• 2 requests to delete 2 documents
• 2 requests to update 2 documents

With 2 requests there won't be much of a change, but you might want to delete hundreds of documents at the same time. There, the difference would be huge.

---

After reading these, what are your thoughts? Do you still consider making one request instead of two crucial? If yes, can you explain in detail your reasons why that is a problem (like coding time, app performance, server load...) please?

[punitdiwan]

I think it's best to explain my business needs and maybe you guys can guide me in the right direction.

I need to register two types of users, One is the patient type and the other type is the doctor. The Platform owner can register both types of users. I am storing user type in the preference because I need this info at the time on login so that I can do things based on it.

Currently, this is how I am doing.

When the platform owner registers using create account API on the client-side, I get the user ID of the new user. Then I invoke a serverless function from the frontend using “sdk.functions.createExecution” by passing type and new userID as data from the client-side.

On the server-side, I update the user preference of the user based on the data I received. As The new user ID is also part of the data, I received, I separated the user ID from the data object at the server-side.

Am I doing right? I can not use “create user event” as I need to pass additional data while creating the account and create account function on the client-side only takes 3 parameters.

It will be nice if I can pass additional data wth create account function one client-side, I can process this create account event. Can I make it better or am I missing anything? Please guide me.

Thanks
Punit

[Meldiron]

Summary: Punit is using preferences as a way to identify the type of account. He wants to do it in 1 request, so he receives the correct user preferences object inside function execution triggered by the account creation event.

---

User preference is a really specific feature for a really specific use case. Preference is only visible to the user itself (and server SDK), and can be modified by the user (and server SDK).

I don't think you should use preferences, because then the client can change his own status from patient to doctor.

In your example, I would suggest creating two teams, one for team:patients and one for team:doctors. With that, you can still easily access it in server SDK, by checking users' memberships. Additionally, you can natively use these permissions in Appwrite Database and Appwrite Storage, to (for example)only allow doctors to create documents in collection prescriptions.

---

Other than that, I think you are doing it perfectly. In your scenario, an event for account creation would not hold the information you need - which type of account it is. I think it's totally fine to create execution after creating an account. If you really wanted to automate this, in my example, you could execute a function with the event of joining a team. Thanks to 0.14, you can run two separate functions depending on which team they joined - which type of account they are.

If you wanted to stick with your solution, instead of executing the function on the users.*.create event, you would do it on users.*.update.*.prefs event. But yes, it is still 2 requests, and due to client issues (network), you may end up with stuck accounts - those without preferences. You will need to do additional frontend work to prevent these.

---

With all of that said, I can see why it can be a problem when there is no way for you to pass extra data into event-triggered execution. On one hand, you want to use it to keep everything automated (executing it manually might fail due to network problem, and now you need to handle stuck accounts), on the other hand, having a parameter for extraEventData in almost all endpoints doesn't make too much sense to me (currently).

(cc @eldadfux last paragraph)

[punitdiwan]

Thanks, @Meldiron for your valuable input. I totally agree with your suggestion of creating a separate team for doctors and patients. I have added a team for patients and doctors. Now there is some more data like date of birth, address, hospital, etc. So, I decided to add a Profile Collection. where I can store one-to-one related data. As some details are different for doctors and patients, so I created details columns where I am storing JSON strings with a full-text index. So that, the complete profiles for both doctors and patients can be sorted.

I am ignoring the number of requests at this moment. By the way, now there are three requests where are as under.

1. Add User
2. Add Profile Collection
3. Add Team Membership

I have handled them in the front end by putting them in async / await under try/catch and checking the response before moving to the next step. However, I can remove all calls by adding a single server function and invoking it for the client side.

Anyway, what do you suggest, the step-by-step methods from the client-side or whole at one shot using a single server function.

Here I feel that additional data in all created and updated events may be useful to make things easy on the server-side and maybe one operation can be done on the client-side and later operations can be completed on the server-side.

Waiting to hear from you.

Regards,
Punit Diwan