🚀 Feature: accept optional name parameter in createMagicURLSession

[PratikDev]

🔖 Feature description

The account.create method takes 3 required parameters and 1 optional parameter. The 4th one is the name of the user. But the catch is that no other method related to account creation accepts this name parameter. This feature covers this issue. Though the title only mentions the createMagicURLSession, it can be implemented in createPhoneSession method as well. These endpoints just need to accept one more parameter called name which we can pass into the DB

🎤 Pitch

In my use case, I was thinking of giving all my users a default username. And the only sign-in method I was using was Magic URL. So there was no way for me to pass the name on the same payload. The only workaround was to call account.updateName after the sign-in completion, which obviously not a good idea, as it'll hit the server twice. It also won't have any single point of failure, which means if account.createMagicURLSession completes but account.updateName fails for some reason, my system will break.
So that's why I think this feature will be a great idea to extend. If we have this feature, appwrite devs can take username inputs as well from their users, while keeping the Magic URL / Phone Session sign-in method

But if we implement this, as a JavaScript developer, I can see an upcoming tiny confusion working with account.createMagicURLSession in JS. Currently, this method can take 3 parameters, where the first 2 are required and the last one, the url parameter is optional. Currently, it looks like:

account.createMagicURLSession('[USER_ID]', '[email protected]');

OR

account.createMagicURLSession('[USER_ID]', '[email protected]', '[EMAIL_CONFIRMATION_ENDPOINT]');

Now if we add another optional parameter name, it'll look like:

account.createMagicURLSession('[USER_ID]', '[email protected]');

OR

account.createMagicURLSession('[USER_ID]', '[email protected]', undefined, '[EMAIL_CONFIRMATION_ENDPOINT]');

OR

account.createMagicURLSession('[USER_ID]', '[email protected]', '[NAME]');

OR

account.createMagicURLSession('[USER_ID]', '[email protected]', '[NAME]', '[EMAIL_CONFIRMATION_ENDPOINT]');

Now this might become confusing to the developer to think which param should be undefined for which case. A possible solution for this is to follow how React handles props in their Functional Components. With an object reference. The idea is to pass one object containing all the necessary parameters, instead of passing multiple parameters.

An example might look like:

account.createMagicURLSession({
      userId: '[USER_ID]',
      email: '[email protected]',
      name: '[NAME]',
      url: '[EMAIL_CONFIRMATION_ENDPOINT]',
    });

In this approach, the developer doesn't need to think about what should be undefined and what's not. They can just pass the props they want in the object. If they want name to be undefined and url to be declared, they can do:

account.createMagicURLSession({
      userId: '[USER_ID]',
      email: '[email protected]',
      url: '[EMAIL_CONFIRMATION_ENDPOINT]',
    });
// No need to specify `name` as undefined

For vice-versa:

account.createMagicURLSession({
      userId: '[USER_ID]',
      email: '[email protected]',
      name: '[NAME]',
    });
// No need to specify `url` as undefined

Following this, we can then easily introduce any new optional parameter (maybe phoneNumber) in the future that can be passed to the method.

Now to follow this approach, it'll require to change all the functions to this structure (to keep the same structure for all) and also the corresponding docs. Which is surely a headache. Now the Appwrite team will know better which approach should be followed.

And if this feature gets the maintainers' focus, I'm pumped enough to work on this

👀 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

[tessamero]

@PratikDev thank you for submitting this feature request, this is something our engineering team is discussing since you've submitted it and we will follow up when we have an appropriate update to provide :)

[PratikDev]

Thanks. Waiting for the update🕐

[eldadfux]

Hey @PratikDev, thanks for the suggestion.

The reason you can provide the name when creating an account is because this is part of the CRUD for the account resource, while createMagicURLSession is designed as part of the CRUD of the session resource.

The reason why we didn't provide the name parameter together with session creation will create coupling between account and session in a way that is not suitable with how the Appwrite REST API is designed and might cause many inconsistencies with other APIs.

On top of that, if we did provide as an optional parameter, you would be forced to provide the user name in every session creation otherwise the name would be reset to an empty string which is something that we do allow today.

If you want to avoid making two requests I can suggest a few options:

1. Abstract this behavior behind an Appwrite Function. This way you could verify the success of both calls on your own custom endpoint.
2. Use the GraphQL API to make both call in one request. This has the ability to improve network latency and might be simpler than writing a function if you're comfortable with GraphQL. The downside, this will come without the same flexibility of an Appwrite Function.
3. Make two requests on your client side. Trigger the 2nd request in the background as an optimistic update and in case of failure, use the API callback to decide how to act. The good thing? If you're using Appwrite Cloud you're not charged by number of requests.

[PratikDev]

Screencast from 08-27-2023 12:06:03 AM.webm
In the above screen video, I did a small test within my app that uses the createMagicURLSession feature. As you can see, it sets the name only while creating the user. But for later session creations, it keeps the previous name, even if we pass a different name or don't pass any name parameter. So we're not really forced to provide a username in every session creation.

And the only changes I made in app/controllers/api/account.php are shown in the above ss. I just added a new param name and passed it into the user creation function. Is this breaking the core design of Appwrite REST APIs? Or I'm missing something?

[PratikDev]

hi @eldadfux, It's been two weeks. any update?

[PratikDev]

it's been nearly two months. should I close this issue? @eldadfux @tessamero @joeyouss @abnegate