User resource - management doubts

Hi all,

When we complete OLMIS-4896, OLMIS-4833 and OLMIS-4902 we will have three user resources in three different services:

  1. auth’s user resource that contain details like username, password and enabled flag
  2. reference data’s user resource that contain details like first/last name, jot title, etc.
  3. 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.

Regards,

Lukasz


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

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Hi Łukasz,

To me, the first approach feels the most reasonable and best conforming the micro-service architecture of our system. I’m curious about what would we use for identifying which of the resources relate to the same user. We wouldn’t be able to reference user id from the reference data service as it wouldn’t be always available. Would we replace it with authUserId? Wouldn’t it make notification and reference data dependable on it? How would it fit in our architecture?

Best regards,
Nikodem


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

···

On Fri, Jun 15, 2018 at 7:39 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

When we complete OLMIS-4896, OLMIS-4833 and OLMIS-4902 we will have three user resources in three different services:

  1. auth’s user resource that contain details like username, password and enabled flag
  2. reference data’s user resource that contain details like first/last name, jot title, etc.
  3. 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.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com


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

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wLW5TFKqE1ex7cPQmTyM9jnkJPgqadHp3jFpBNVq78FA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

Hi Nikodem,

Currently I made that the auth’s user and the reference data’s user has the same id field because of issue related with data consistent when user is saved/updated. We could do the same here all three sub-resources would have the same id field so it would be easy to manage them.

I called this approach as “each resource is independent” but in reality the auth resource is needed because otherwise user could not log into the system.

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 15, 2018 at 7:39 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

When we complete OLMIS-4896, OLMIS-4833 and OLMIS-4902 we will have three user resources in three different services:

  1. auth’s user resource that contain details like username, password and enabled flag
  2. reference data’s user resource that contain details like first/last name, jot title, etc.
  3. 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.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com


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

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wLW5TFKqE1ex7cPQmTyM9jnkJPgqadHp3jFpBNVq78FA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Hey Łukasz,

I think the first option of “each resource is independent” makes the most sense. However, I don’t think the system would be usable for a user that is not saved in reference data either, since many other services consult user info from reference data.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 15, 2018 at 7:39 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

When we complete OLMIS-4896, OLMIS-4833 and OLMIS-4902 we will have three user resources in three different services:

  1. auth’s user resource that contain details like username, password and enabled flag
  2. reference data’s user resource that contain details like first/last name, jot title, etc.
  3. 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.

Regards,

Lukasz

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**

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

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wLW5TFKqE1ex7cPQmTyM9jnkJPgqadHp3jFpBNVq78FA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

I’m not sure I’m following this, and my internet isn’t good enough to load everything, however I think I agree with what you’ve laid out in option 1, with a big caveat: The user is not owned by the Auth service.

Lets step back a second and think about the role of each of these services:

  • Reference Data owns the canonical definition of meta-data.

  • Auth owns credentials and the workflow of obtaining new credentials (i.e. forgot password reset).

  • Notification Service hasn’t owned anything recently, except the definition of a channel ignorant Notification. Channel here means things like email, SMS, voice/IVR, in-app push, etc. Except for email the rest of the channels are aspirational at this point.

Given this, when it comes to a User I would expect:

  • Reference Data continues to own the canonical definition of a User. i.e. you can’t have a User, without having an entry in Reference Data.

  • Auth continues to own credentials: Passwords, Service credentials, etc.

  • Notification should continue to own a Notification, and I think it should own contact information (e.g. someone’s email address, phone number, etc).

With this breakdown, the actions should be separate: I can mutate a User, separate from mutating a person’s Credentials or contact information. In-fact I should be able to have a User without credentials or contact information. I should not be able however to have a User’s Credentials, without a User. That level of logical inconsistency isn’t terribly difficult to deal with (fail valid User credentials where there’s no longer a valid User), and can be cleaned up with a batch job at some later date.

Perhaps I misread something here, but I did want to be sure that Reference Data keeps owning the definition of a User and the majority of their canonical Profile, and that the other Service should own additional resources that add-on to that canonical definition.

Best,

Josh

···

On Saturday, June 23, 2018 at 12:02:32 AM UTC+3, chongsun.ahn wrote:

Hey Łukasz,

I think the first option of “each resource is independent” makes the most sense. However, I don’t think the system would be usable for a user that is not saved in reference data either, since many other services consult user info from reference data.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Jun 15, 2018, at 12:11 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi Nikodem,

Currently I made that the auth’s user and the reference data’s user has the same id field because of issue related with data consistent when user is saved/updated. We could do the same here all three sub-resources would have the same id field so it would be easy to manage them.

I called this approach as “each resource is independent” but in reality the auth resource is needed because otherwise user could not log into the system.

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

On Fri, Jun 15, 2018 at 9:02 AM Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Łukasz,

To me, the first approach feels the most reasonable and best conforming the micro-service architecture of our system. I’m curious about what would we use for identifying which of the resources relate to the same user. We wouldn’t be able to reference user id from the reference data service as it wouldn’t be always available. Would we replace it with authUserId? Wouldn’t it make notification and reference data dependable on it? How would it fit in our architecture?

Best regards,

Nikodem

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 15, 2018 at 7:39 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

When we complete OLMIS-4896, OLMIS-4833 and OLMIS-4902 we will have three user resources in three different services:

  1. auth’s user resource that contain details like username, password and enabled flag
  2. reference data’s user resource that contain details like first/last name, jot title, etc.
  3. 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.

Regards,

Lukasz

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**

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

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wLW5TFKqE1ex7cPQmTyM9jnkJPgqadHp3jFpBNVq78FA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

**

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

**

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

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yy%2BASnhz%3D3cyQQWKR8-9zGKEpTtUWuBTjtPFRJktT9eA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Hi Josh and Chongsun,

Thanks for replies. I would like to make sure that I understand correctly:

  • reference data’s User resource is mandatory

  • auth’s and notification’s resources depends on above resource

  • all three resources should be handle by endpoints that are in the same service as resource

If those assumptions are correct, I will create an epic to change current approach in which all create/update requests must go though the auth service.

Regards,

Lukasz

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Thanks Lukasz, that sounds correct. Please update the epic.

···

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

The epic OLMIS-4983 has been created. Soon there will be tickets.

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com