toggle quoted messageShow quoted text
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@...
+ Jason Bonafide
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.
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.
EdgeX Foundry co-founder & TSC Vice-chairman
On EdgeX Slack @ jpwhite
On Thu, 12 Dec 2019 at 21:57, Huaqiao Zhang (c) <huaqiaoz@...
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
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
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!
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.
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.
Director of Software Engineering (DMTS)
Core Working Group Chair of
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
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
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
Please advise if this ultimately something of interest and if so, how would you recommend that we can incorporate this feature?