Meteor.user()

[adamdawkins]

Hey @ozsay, thanks so much for putting this package together. I was working on this exact thing myself and this is a very elegant solution.

One question, once I've logged in on a consumer, Meteor.userId() returns a userId, but Meteor.user() returns null. Is that by design? and if so, how do I populate Meteor.user(), or do you just access the logged in user data separately?

[ozsay]

Thanks @adamdawkins for the feedback.

Actually, I was thinking about adding this feature but due to limited resources I haven't got the time to work on in. My idea was that each service in the cluster will keep it's user data and fetch it from it's database (Not from the accounts user collection). That way, you'll have a complete separation of logics.

Is this implementation fills your needs or do you need the user data from the accounts collection?

[adamdawkins]

Not sure on the heat approach yet, but I was planning on only the provider
having the user data, at least for login, and the other services perhaps
only extending that data (with their own databases). So I was going to send
/ retrieve all user data from the Provider so that it's all in one place.

Not sure if that's the right approach though.

In your approach, how do you get any initial user data from the provider in
the first instance? Like if I've logged into App 2, the provider had
returned me a userId, but that user id isn't in App 2's database.

El El mié, 3 feb 2016 a las 21:04, Oz Sayag notifications@github.com
escribió:

Thanks @adamdawkins https://github.com/adamdawkins for the feedback.

Actually, I was thinking about adding this feature but due to limited
resources I haven't got the time to work on in. My idea was that each
service in the cluster will keep it's user data and fetch it from it's
database (Not from the accounts user collection). That way, you'll have a
complete separation of logics.

Is this implementation fills your needs or do you need the user data from
the accounts collection?

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[ozsay]

My goal with this approach is to implement it close to a micro-services architecture.

example:
I have a shop app so I'll probably need a billing service (App 1), email service to notify about purchases (App 2) and the main app (App 3) that is the UI (which contains the accounts service that handles signup, login...)

App 3 may contain user data such as username, purchases history etc..
App 2 will contain the user email
App 1 will contain the user billing information (credit card, paypal account...)
they can all share the same userId to keep the data integrity.

I don't think that there is a right approach to it. It just the implementation that close to your project architecture.

[adamdawkins]

Ok, I don't think we're far off, I'm also basing my implementation on the
microservices approach, but there is a difference - that I'm hoping
cluster-accounts can solve.

I have a suit of apps that clients may use, but I want them to be able to
have a universal login across the whole suite.

To do this I was planning on keeping all user data in a "User data"
microservice, that would also handle authentication; and the other
applications would check with that application for authenticating the user.

Similar to what @arunoda did in
https://github.com/bulletproof-meteor/bullet-microservices-beyond-basics/tree/client-search,
except where the authentication doesn't sit with the current client.

On Thu, 4 Feb 2016 at 09:12 Oz Sayag notifications@github.com wrote:

My goal with this approach is to implement it close to a micro-services
architecture.

example:
I have a shop app so I'll probably need a billing service (App 1), email
service to notify about purchases (App 2) and the main app (App 3) that is
the UI (which contains the accounts service that handles signup, login...)

App 3 may contain user data such as username, purchases history etc..
App 2 will contain the user email
App 1 will contain the user billing information (credit card, paypal
account...)
they can all share the same userId to keep the data integrity.

I don't think that there is a right approach to it. It just the
implementation that close to your project architecture.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.