The balance between client and server functionality

Question

I want to bring the discussion that started in our teams and get your opinion about it.

Assume we have an user account which could have different credentials for authentication and associated email to recover. An user has possibility to do signup with an email or use his social profile to complete signup process.

As an Rest API from the backend to client looks like:

1. Create account
2. Authorise
3. Update user data
4. Link social account
5. Register email
6. Verify email

In addition our BE is distributed and divided between several services/servers/clusters. So different calls are related to different end points. As well we have different client - mobile native applications, web application.

The usual registration flow looks for the client like this:

1. Ask user for email
2. Create account (Rest)
3. Authorise (Rest)
4. Ask user for his display name
5. Update data (Rest)
6. Register email (Rest)

And future possible calls:

1. Verify email
2. Link social account to user

With the Facebook signup:

1. Ask user to login to FB
2. Create account (Rest)
3. Authorise (Rest)
4. Link FB (Rest)
5. Register and verify FB user email (Rest)
6. Update user name based on FB data (Rest)

But all these steps are possible to do on backend. So we proposed to have another end point which will hide/combine different calls on BE and return whole process result to the clients:

1. Ask user for FB login
2. New user with FB (proposed Rest)
3. BE is doing register/link verified email/update user data/authorise

The pros for this approach:

1. No more duplication of functionality between clients
2. Speed up the networking and user experience

The cons for this approach:

1. Additional work for backend
2. Probably most complex scenarios in future updates

I would like to get your opinion or experience with this situation. Especially if you already experienced point "Probably most complex scenarios in future updates" from against reasons.

Answer 1

Point 2 is reasonable argument against the use of the given approach. I worked on something similar where user can have data in different form depending on the entry point. Obviously, complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows. If you do not have use cases with insanely high branching factor, you can easily manage complexity if you focus on few things.

Try to make things readable at each level. Whether you are exposing your API or writing code, keep everything meaningful both for your programmers and API users. If you take care of readability, smaller things like naming etc., things will become less complex.

Do not rely on data patterns in your storage expect a few key fields, you will have to be careful while defining what is you always going to have. For example, you have created your API assuming, you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory. You might have hard time changing your code for that.

Follow standard coding principles that our elders have been teaching us like KISS, SOLID, design patterns etc. This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.