0

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.

  • what is #2? there are many "2." – k3b Oct 23 '13 at 15:30
  • Sorry and updated – Eugen Martynov Oct 24 '13 at 5:13
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.

  • Than you for answering, but all three recommendations are common for all programming but I'm interested in our particular design/architecture case. Most probably question is hard to understand. I will edit it – Eugen Martynov Oct 23 '13 at 6:08
  • Id change "don't rely on data patterns" to "manage the flow of dependency in your system" you should not have a direct dependency from any aspect of your storage to the use case that results in the creation of the data you plan to store. Instead you should have a layer in the design which is responsible for getting the data into the 'pattern' the storage mechanism requires. An adaptor layer. This allows your design to be decoupled and reduces the impact of the introduction of a new use case. Only the adaptor layer needs to be updated. – SteveCallender Nov 25 '15 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.