Re: 回复: EdgeX UI PR #138

Cloud Tsai

Hi Michael,

Sorry for the unclear statement.  Let me try to explain my idea in an example.
Here is the device client initialization code snippet
mdc = metadata.NewDeviceClient(
ServiceKey: clients.CoreMetaDataServiceKey,
Path: clients.ApiDeviceRoute,
UseRegistry: registryClient != nil,
Url: Configuration.Clients["Metadata"].Url() + clients.ApiDeviceRoute,
Interval: Configuration.Service.ClientMonitor,
endpoint.Endpoint{RegistryClient: &registryClient})
It only allows HTTP communication now, and my idea is to add some security related parameters into EndpointParams, such as token.
Then, the UI backend can use DeviceClient to communicate with Core Metadata through HTTPS.
In a distributed environment, the service to service interaction might go through different API Gateways on machines.
It's just a thought, and I can help the design and implementation if you and Trevor agree with this direction.

On Thu, 19 Dec 2019 at 21:21, <M.Estrin@...> wrote:

I'm not sure what you're proposing for changes to the client code of go-mod-core-contract.

There's a basic design decision to be made on which side of Kong the UI backend will reside.

If outside, the UI backend would be considered external to the EdgeX installation and should be required to communicate with the EdgeX services via Kong (i.e. the same as any other northside service).

If inside, the UI backend would be considered internal to the EdgeX installation and should communicate with the EdgeX services directly regardless of where the services reside.  I believe the Security Working Group has plans to harden internal EdgeX service-to-service communication in the future road map.  In this scenario, the UI backend would need to be hardened along with every other internal EdgeX service.  I would expect service-to-service communication changes to be limited to go-mod-core-contracts.  That is, I'd expect the UI backend to use go-mod-core-contracts as it exists today to communicate with individual services.  This would limit future rework required to accommodate security-related changes.

From: Cloud Tsai <cloud@...>
Sent: Thursday, December 19, 2019 7:02 AM
To: Estrin, Michael; Conn, Trevor; Zeng, Tingyu
Cc: Zhang, Huaqiao (c); EdgeX-TSC-UI@...; Jim White; Bonafide, Jason
Subject: Re: [edgex-tsc-ui] 回复: EdgeX UI PR #138


Hi Trevor, Michael, and Tingyu,

About calling services via API Gateway, I thought we had better make some implementation in the client code of go-mod-core-contract.
The UI backend is implemented in Golang, so it should be able to leverage the client code of go-mod-core-contract.
We could give some security related parameters when initializing the clients, and they would become to communicate with other services through API Gateway.
This would also be helpful for the distributed environment.  For example, deploying core-data and core-metadata on different machines and they are all protected by an API Gateway on individual machines.
What do you think?

On Thu, 19 Dec 2019 at 20:44, Michael Estrin <m.estrin@...> wrote:

​+ Jason Bonafide

From: EdgeX-TSC-UI@... <EdgeX-TSC-UI@...> on behalf of huaqiaoz via Lists.Edgexfoundry.Org <>
Sent: Thursday, December 19, 2019 5:18 AM
To: Jim White
Cc: EdgeX-TSC-UI@...
Subject: [edgex-tsc-ui] 回复: EdgeX UI PR #138


HI all

About how UI agents request access to the edgex service behind api-gateway

we should know a few things:
  • If the user uses the api-gateway service (actually it is kong and vault), access authorization authentication is enabled.
  • If we want UI to agent any requests to access edgex behind api-gateway service, a valid access token is required
  • Once the UI adapts the api-gateway, the user must start the api-gateway service when the user uses the UI 

In order to do this, we need to do or solve the following problems:
  • Remove gateway tab on the UI menu, there is no term "gateway" any more.
  • UI backend server needs to access to edgex-api-gateway service and retrieves the access token, but there is no remote apis to communicate with api-gateway service, the access token can only be got by CLI.
  • The user's registration also cannot be associated with a specific valid access token,because user additions also require the command line of the api-gateway service
  • If the user starts edgex with source code, the UI cannot be used anymore because kong and vault can only be in container now.

So I think api-gateway is needed to provide remote apis so that the UI can get access tokens at run time.


发件人: Jim White <jim@...>
发送时间: 2019年12月14日 4:11
收件人: Huaqiao Zhang (c) <huaqiaoz@...>
抄送: Gavin Lu <gguanglu@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; Jason Bonafide <jbonafide623@...>; Tiejun Chen <tiejunc@...>; Jason Bonafide <jason_bonafide@...>; edgex-tsc-ui@... <edgex-tsc-ui@...>
主题: Re: EdgeX UI PR #138
forwarding this message to the UI forum for historical tracking and record of any decisions off this thread.

I recommend we take this up as part of the discussion in the next UI project meeting.

The EdgeX UI was created as a kind of tool for conference demos and simple UI for developers.  I don't know that it will ever be used as a production grade interface without a lot more effort.  We can let the current UI team (led by Gavin) tell us if they have the resources to spend to make it something that can be used with the API gateway (either now or in the future).  And load balancers and enterprise level issues are not something we are addressing much in any part of EdgeX yet - so I have concerns about trying to drag the entire project in that direction without some overarching coordination and timing from the community on that.

Priority of effort for Geneva release in my opinion should be:
a) addressing the EdgeX API changes in the UI
b) addressing the new types of services that the API does not support yet (namely the application services, system management, and potentially new rules engine)
c) insuring the UI is made aware of new sensors that are auto provisioned

Beyond that, there are lots of directions we could take such as better HA support, managing multiple instances, better dashboarding and display of the sensor data, etc. but I view that as future roadmap release items unless we have more resources to throw at the development needs in this area. 
Jim White
EdgeX Foundry co-founder & TSC Vice-chairman
On EdgeX Slack @ jpwhite

On Thu, 12 Dec 2019 at 21:57, Huaqiao Zhang (c) <huaqiaoz@...> wrote:
Hi all.

And Jason Bonafide

I know what you want, you want to call the APIs of all microservices through the API gateway , but if you modify it this way will affect the previous code if user not using API gateway service, i did't test it whether it will cause other functions not work.

My suggestion is that you should know how API gateway agent the http requests firstly, if you know it well, you will find this UI server based on the principle of API gateway, why? because there is no API gateway project when UI project was released. So, edgex-ui-go has to some extent taken on the role of an api-getway back-end service.

so i think there are two ways to solve the problem:

Firstly, based on microservices architecture principle, all microservices architecture projects should have an api-gateway service , so update Edgex-ui-go adapted to API-getway microservice, then users must start API-gateway microservice when users use edgex foundry.

Secondly, to update the UI coding logic, the basic idea is to add the default statement to the switch-case statement, to add the api-gatway path, but I haven't figured that out yet!


发件人: Gavin Lu <gguanglu@...>
发送时间: 2019年12月13日 10:52
收件人: Conn, Trevor (EMC) <Trevor_Conn@...>; Jason Bonafide <jbonafide623@...>; Huaqiao Zhang (c) <huaqiaoz@...>; Tiejun Chen <tiejunc@...>
抄送: Jason Bonafide <jason_bonafide@...>; Jim White <jim@...>
主题: Re: EdgeX UI PR #138

Do you mean ?


I see that’s reverted by Tiejun & Huaqiao.


Tiejun/Huaqiao, could either of you provide comments in the page? So we could elaborate more details and collaborate easier.






From: "Conn, Trevor" <Trevor_Conn@...>
Date: Friday, December 13, 2019 at 2:25 AM
To: Jason Bonafide <jbonafide623@...>, "Huaqiao Zhang (c)" <huaqiaoz@...>, Tiejun Chen <tiejunc@...>, Gavin Lu <gguanglu@...>
Cc: Jason Bonafide <jason_bonafide@...>, Jim White <jim@...>
Subject: RE: EdgeX UI PR #138


+ Gavin


I’m not aware that we ever received a response from the UI team on this thread. The PR was rolled back after it was approved. The contribution is something that we (Dell) provided based on internal work we are doing to host EdgeX in Kubernetes, so we require this feature.


Please advise.


Trevor Conn

Director of Software Engineering (DMTS)

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech


Round Rock, TX USA



From: Conn, Trevor
Sent: Wednesday, November 27, 2019 10:01 AM
To: 'Jason Bonafide'; Zhang, Huaqiao (c); Chen, Tiejun (VMware)
Cc: Bonafide, Jason
Subject: RE: EdgeX UI PR #138


+ Tiejun


From: Jason Bonafide <jbonafide623@...>
Sent: Wednesday, November 27, 2019 9:46 AM
To: Zhang, Huaqiao (c)
Cc: Bonafide, Jason; Conn, Trevor
Subject: Re: EdgeX UI PR #138



CC-ing Trevor


On Wed, Nov 27, 2019 at 10:34 AM Jason Bonafide <jbonafide623@...> wrote:



As discussed I wanted to follow up with an email based on some of the PR comments :)


As you mentioned in the PR comment. I recognize that the UI project was created without an API Gateway in the EdgeX ecosystem. My thoughts for the API Gateway support is that as EdgeX expands is used in more Enterprise Solutions, the need for supporting common MicroService Service Discovery Patterns (i.e. API Gateway) might become more in demand.


The use case I had for this is deploying EdgeX in Kubernetes. The main issue here would be Ingress routing. Due to the fact that, edgex-ui-go only supports configuring a host and port essentially means that the application would need to be directly available at said host and port. In several Enterprise solutions, routing techniques could include Load Balancers and Cluster Ingress Routing (Kubernetes). With that, Ingress/Egress Security concerns, we've opted to go with an API Gateway pattern as our service discovery pattern along with many other reasons.


The above kind of grazes over the requirement we have and why the suggestion of the issue itself.


With respect to the PR, by using an empty default Uri, it would preserve the original proxy functionality. I tested the backwards compatibility by deploying edgex using docker with positive results. My changeset would certainly add flexibility. I would agree, that my PR is not elegant, if that were to deemed as an "OK" approach, I would lean on your thoughts as to naming conventions because "CoreDataPath" and "CoreDataUri" could be incredibly confusing and seen as superfluous.


Please advise if this ultimately something of interest and if so, how would you recommend that we can incorporate this feature?




Jason Bonafide

Best Regards,
Cloud Tsai

Best Regards,
Cloud Tsai

Join to automatically receive all group messages.