global_id support

[alexeylightit]

Problem:
New tasks requires some knowing about full model type, while frontend can't know it, for example:
PossibleOutcome:

def transform_result_type
    self.result_type = "Perx::#{result_type.classify}::Entity"
end

Solution:
GlobalID uses different connections from Settings for each service to discover the model.
Benefits:

• no need in type + id - gid field is enough
• gid from the same service doesn't use any service-discovery objects - default models used instead

How to use:
Each Model, same as each Resource has :gid field.
ServiceLocator.locate(@model.gid)

Problem 2:
Frontend hardcode:

attributes: {
        amount: data.amount,
        start_date: data.start_date,
        source_type: 'Ros::Reward::Entity',
        source_id: data.source_id,
        code_type: data.code_type,
        code: data.code
}

Frontend solution:

attributes: {
        amount: data.amount,
        start_date: data.start_date,
        source: data.source_gid,
        code_type: data.code_type,
        code: data.code
}

[rpbaltazar]

As discussed, I think that we can achieve this by using the URN instead of adding yet another attribute.
@alexeylightit what do you think?

[alexeylightit]

As discussed, I think that we can achieve this by using the URN instead of adding yet another attribute.
@alexeylightit what do you think?

Since we use urn only inside jwt right now - I don't know if it's a good idea to invent a wheel instead of change urn to gid

[rpbaltazar]

The urn is already part of the serialized attributes for all the records. The main advantage of the URN in comparison with the gid is that the urn has information about the tenant as well, so we can pinpoint exactly to the resource.

Since we are proposing a GlobalId Locator based on the gid wouldn't it behave the same if we rely on the urn instead?

"attributes": {
  "urn": "urn:whistler:loyalty::666666666:program/1",
  "created_at": "2019-11-19T02:23:04.506Z",
  "updated_at": "2019-11-19T02:23:04.506Z",
  "gid": "gid://loyalty/Program/1",
  "name": "Absolutely Loyal",
  "unit": "LoyalDolla",
  "status": "draft",
  "custom_tiers_count": 0
},

[rpbaltazar]

To add to what i was saying, I think that this idea goes in line with rails/globalid#39 which is our usecase. I think it might be worth to explore as it would solve the problem of building a mapper between rails classes and readable attributes.

[alexeylightit]

To add to what i was saying, I think that this idea goes in line with rails/globalid#39 which is our usecase. I think it might be worth to explore as it would solve the problem of building a mapper between rails classes and readable attributes.

It doesn't actually and I have working examples.

[alexeylightit]

The urn is already part of the serialized attributes for all the records.

By the word 'using' I've ment we are doing something with this field. In other cases it's just exists

The main advantage of the URN in comparison with the gid is that the urn has information about
the tenant as well, so we can pinpoint exactly to the resource.

We don't need such information bc when we are calling any service-discovery model - it goes with default http request which already contains token. And this token has all the information we needed to reach the resource

Since we are proposing a GlobalId Locator based on the gid wouldn't it behave the same if we rely on the urn instead?

No it wouldn't. GlobalId Locator has it's own structure.