Hypervisor latency

[jdknives]

Describe the bug
When visiting a visor overview page in the hypervisor, it takes a substantial amount of time (roughly 3-4 seconds) for the hypervisor to display the information of the visor both in the app and routing tab. That seems like a long time given that a roundtrip ping time is about 400 ms. Maybe we can improve the return times of these calls.

[Senyoret1]

#436 solves a small part of the issue, as it adds a cache to avoid having to retrieve the data after navigating if certain conditions are meet, but it is still slow to get the data just after opening the details of a visor.

The main problem is that the manager has to send multiple requests for getting all the data that is shown in the UI. A lot delay can be prevented if all the data is obtained in one request instead of many.

At this moment, for showing data in the visor details page, the manager makes these requests:

• GET api/visors/${nodeKey}: to get the basic info about the visor.
• GET api/dmsg: to know to which dmsg server the visor is connected.
• GET api/visors/${nodeKey}/health: to be able to show the state of the services.
• GET api/visors/${nodeKey}/uptime: to know for how much time the visor has been online.
• GET api/visors/${nodeKey}/transports: basically just to know how many data has been uploaded and downloaded, as the transport list returned by the first call does not include that information (although it includes all the other data this call returns).
• GET api/visors/${nodeKey}/routes: to get the routes list, as the first call only returns how many routes the visor has.

If all that data is returned in just one call, the performance will be better.

As a related note, there is something else important about the GET api/visors/${nodeKey}/routes API endpoint: it would be good to show more information in the route list, but currently that endpoint only returns the key and the rule of the route. For being able to show more info, it would be needed to call the GET api/visors/${nodeKey}/routes/${routeKey} API endpoint for each route (which would make the current issue even worse), create a way to parse the rule localy o add the data to the GET api/visors/${nodeKey}/routes API endpoint.

I'm not sure what of the 2 last options would you prefer. For parsing the rule in the front end, I checked and it should be possible to create a parser in TypeScript or to compile the current go code using the wasm compiler, for using the in the manager the same code used by the backend. Maybe one thing to take into account is that the wasm compiler has been working almost the same since Go 1.11, but it is still marked as experimenta in the documentation: ( https://golang.org/pkg/syscall/js/#ValueOf . About adding the data to the current API, maybe adding a param to the current GET api/visors/${nodeKey}/routes endpoint to make it return all the data would work.

[nkryuchkov]

@Senyoret1 An endpoint that returns all the data will be implemented in #451.

[nkryuchkov]

@Senyoret1 I've implemented the endpoint in #451, it's GET api/visors/${nodeKey}/summary. It contains the information you listed and extended route information. By the way, the extended route information may be fetched by using the GET api/visors/${nodeKey}/routes?summary=true endpoint.