Make project link nodes application aware

[Steve-Mcl]

Description

Currently, the Project Link Nodes access the depreciated teams/<team>/projects endpoint for a list of all instances.

A future update to the project should use the replacement endpoints to provide a hierarchal view to permit targeting by application->instance

Requested By

• Elevate-it

Epic/Story

No response

[lgrkvst]

Nice to have: include applicationId in msg.projectLink for those cases where responses are application-specific.

[Steve-Mcl]

Not explicitly called out so making an additional comment:
Instance owned devices can be targeted directly by project-link-out and project-link-call.

As part of making the project nodes play nicely when used with application-bound devices will be the ability to target them like you can an instance-assigned device. That would permit users to use project-out and project-link-call nodes from instance -> app-device (and vice versa).

[Steve-Mcl]

following a discussion in engineering meeting today, I am moving this back into TODO.

Any Other Business:

• Steve: Project nodes
  • project-nodes have been around since before the concept of applications and therefore permit instances from one application to communicate with instances in any application belonging to the team. As I see it, have 3 immediate/obvious choices to support application awareness.
    • 1. Simply provide the application name as a means of filtering / organising the choice of instance (this means the project nodes retain the same functionality for cross-application communication / backwards compatibility)
    • 2. Depreciate the project nodes in favour of newer set of "link-nodes" (name TBD) that are strictly scoped to an application (see Rebranding "Project Nodes" #94)
    • 3. Introduce cross-application scoping as an option in the platform (defaulted to permit it for backwards compatibility) that instructs the core + nodes of application choice
  • Joe: My vote is 1 or 2
    • Feel like we need Nick’s voice on this
    • 1 seems like the smallest iteration, but we’ve been asked by ZJ to rebrand PN for a long time, and this feels like a good opp
      • Steve: rebranding (as a facelift) is not insurmountable but a full rebranding (i.e. rename/replace package) might leave us with a legacy package to support. We could re-use the internal node names so that the new package is an in-place replacement, however there is still the question of application scope.
• Joe: How many people are using project nodes?
  • Steve: I know of xxxx and yyyy off the top of my head.
    • FOLLOW-UP: Will see if I can glean anything from logs.
  • Steve: Following discussion with the team, the agreed direction at this time is to update the issue with our discussion and park it until such a time we can discuss with Nick.

FOA @knolleary

[Steve-Mcl]

• FOLLOW-UP: Will see if I can glean anything from logs.

With assistance from @ppawlowski a scan and summation of the logs seems to indicate over the last 1 week, there were 65 unique client IDs (that match the project-nodes signature) suggesting that option 2 may not be the huge battle we expect.

Of course, 1 week is a small sample but it can be used as an indicator in decision making for now.

[Elevate-IT]

We had a call with Ben and Michael today.

Maybe it's helpful to further clarify our use case:
Our goal is to be able to send HTTP requests to a cloud-hosted instance(relay) secured with a token.
This "relay" instance will then forward the message to the configured device agent via the project nodes.
This approach eliminates the need to open an HTTP port within the client's network.

Flow:
External System (HTTP) <-> Cloud "Relay" Instance <-> Device Agent Instance