Repository files navigation

This UI provides visualization of resources and interface to deploy connectivity workflows.

It allows you to:

1. discover network domains
2. create new network domains (stub only)
3. create connections between two network domains
4. view connections between network domains
5. create SLA profiles for aforementioned connections

1. React + TypeScript, redux-toolkit
2. CRA + Craco
3. Ant Design, ag-grid community
4. React Router
5. grpc

You can decide whether the app should run on stub data or on live vmanage servers. You set this in your local.env.local file in the root. IfREACT_APP_BUILD is set tolive the app will try to fetch all the data from vmanage and if it's set tostub it will try to access json-server with data insrc/_db/db.json.In both cases you should follow the steps bellow.

1. Runnpm install from the root folder
2. Setup vmanage servers and Envoy proxy
3. SetupREACT_APP_BUILD to desired setting
4. To start the UI runnpm start from the root. This starts both the actual client and stubbed data from json-server

UI should be available athttp://localhost:5001/

To build your image simply run

docker build -t sample-ui:1.0 .

To push your image to ECR registry tag it and then push

docker tag sample-ui:1.0 229451923406.dkr.ecr.us-west-2.amazonaws.com/awi/sample-ui:1.0docker push 229451923406.dkr.ecr.us-west-2.amazonaws.com/awi/sample-ui:1.0

The current image uses nginx as a base which helped decreasing theimage size to 90 MB and also made it much faster to start the containeras there is no building process during the start but rather servingstatic files.

It is crucial to remember that JS calls implemented in this UI are not sent by theUI process/container but they are coming directly from the web browser or any otherclient used by the user.

In this example, the UI application serves a JS file with alogic that performs a call to the backend service present withinthe same cluster, reachable from the UI on port:8000. Theproblem is that the call will be performed by the Chromiumbrowser used by the client and so it will try to send it tothe localhost on port 8000 which will most likely fail (unlessthe user uses the browser on the same host where the backendserver runs).

So the JS files cannot use the addressing used internally withina server machine or a k8s cluster - these addresses must bereachable from the user's device.

Of course, the backend service does not need to be exposeddirectly but it will be rather hidden behind a reverse proxy.It, however, gives us another problem - the front-end applicationneeds to be aware of the public address which is used by theproxy. It can be solved by a few options:

• using final DNS name - having an actual DNS name associated withour server, we can simply hardcode it. However, it is not agood solution as changing the domain will require rebuildingthe front-end application. Additionally, this solution worksonly if it is expected that there will be only one instanceof front-end (SaaS) but if each potential customer can have his own front-end instance deployed on on-prem systems, itbecomes a problem (even in case of SaaS we still may want todeploy separate production and testing front-end)

• providing address as a runtime parameter - the second option isto use a variable with the address which is set with theenvironment variable or commandline argument. That way theentire system can be deployed, the public address retrievedand then the UI application restarted with modified config(config-map in k8s deployment or docker-compose scripts).However, using variables requires JS server which results inhigher image size and container start-up time. Serving staticJS files with NGinx image saves a lot of size and gives aquick application restart - however it makes it harder touse a configuration variable - such solution would requireeither some nginx libraries/extensions or simple tools tooverride every JS file using that address with a proper value(simple sed script for instance). This solution is alsoproblematic if our public address changes quite often - itwould require constant front-end restarting.

• do not provide an actual address

The last solution is the one we use:

The approach is simple. The JS code describes only endpoints forbackend calls, for instance/grpc/Clouds rather thanhttp://myapp.net.io/grpc/Clouds. If the address is not provided,the client will use the address it used to download a particularJS Document.

For instance, we have entered our UI by specifying127.0.0.1:8080/index.php in the web browser. The page definesone script that calls backend service using/grpc call. Sincetheindex.php page was downloaded from127.0.0.1:8080 thesame address will be used to complete/grpc call giving as aresult the address127.0.0.1:8080/grpc.

This solution has a condition - both UI and the backend needto be reachable under the same address. For that matter, we needa reverse proxy to push our front-end requests to the UI and ourbackend requests to corresponding services. The front-end cannotbe in front as the logic above would redirect all backend callsback to the UI.

For that reason, we have introduced a/grpc prefix for allGRPC backend calls so that we can configure Envoy Proxy todistinguish backend requests starting with/grpc prefix fromthe rest of the calls that should be redirected to the UI.

Thank you for interest in contributing! Please refer to ourcontributing guide.

sample-ui is released under the Apache 2.0 license. SeeLICENSE.