- auth’s user resource that contain details like username, password and enabled flag
- reference data’s user resource that contain details like first/last name, jot title, etc.
- user’s contact details in the notification service
The problem that could occur is how to manage those resources in such way to avoid data inconsistent.
I thought about this a little bit and I would like to show you my propositions:
Each sub-resource is independent
Current approach is that all resources are connected and they have to be created in the same time. Also from the end user perspective there is a single form that contain fields from all resources. We could change that by saying if there is entry in the auth service then user is created, the user can use the system and there is no need to create the rest of resources. If the user decides to create a profile by putting data into the reference data service then the user simple submit a profile form (from UI perspective) or execute correct endpoint in the service (from API perspective). Same for contact details.
With this approach each resource would be created by endpoints in the related service. Currently we use only the auth endpoint and the reference data endpoint is executed by the auth service.
The main issue is that all of our services retrieve current user from the reference data and they ignore resource from the auth service. We probably will have to change that. Also we would need to provide extra checks for some actions. For example we could not assume that there is a related entry in the notification service with contact details.
Single endpoint for save, many endpoints for update
In this approach we still treat all resources as a single user but we divide create/update actions. In other words:
- To create a user the POST endpoint from the auth service would be executed. The endpoint is responsible for putting data into related services. The problem can be correct handling of a situation where sub-resource has been created in one service but there was an error is another service. We probably should execute DELETE endpoint but it could also cause errors.
- To update user the PUT endpoint of the service that keep sub-resource is executed. This is easier to explain from UI perspective because we will have to add update buttons next to each data section. This could be problematic if we would use a single view because user could have problem to understand which update button should be used so it probably be a good to divide sections by tabs
The auth service controls the user resource
We stay with the current approach so the create/update request is handled by the auth service and we provide extra endpoints to the service for other actions on the user. In other words if a user want to execute ANY action on the user resource the user has to use one of the endpoints from the auth service.
Thanks that we have to know only about single service, UI is slightly simplified. Main problem? Endpoints duplication because each non auth action would cause adding extra endpoint to the auth service to give access for a user.
I hope you understand my point of view about managing the user resource in the system after we complete the tickets that were mention on the beginning of this message. If you have any questions, suggestions or you think that we could handle that differently please let me know in this topic. If there will be a need we could discuss this on Technical Committee meeting.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41