--
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 openlm...@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.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@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
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yy%2BASnhz%3D3cyQQWKR8-9zGKEpTtUWuBTjtPFRJktT9eA%40mail.gmail.com.
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 Engineer2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USADIRECT: 1.206.512.1536 CELL: 1.206.910.0973 FAX: 1.206.860.6972SKYPE: chongsun.ahn.vr
On Jun 15, 2018, at 12:11 AM, Łukasz Lewczyński <llewc...@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.
On Fri, Jun 15, 2018 at 9:02 AM Nikodem Graczewski <ngrac...@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
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.
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 | chongs...@villagereach.org
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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.
--
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...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/157a65b7-96e6-401f-87b5-8fe3346d6225%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yZg3OGminXcrGncRe__SUq2GUT6mBOM1CtLbPuabL5cw%40mail.gmail.com.