Discovery service implementation

[calvellido]

We need to create a service to get to know which network structure is available to the client to get information from. This would eventually be an endpoint where we connect to get a tree of all the possibles microservices and nodes to show, and then select a specific one to start consuming metrics.

[eperinan]

In this branch https://github.com/frees-io/freestyle-opscenter/tree/ep-12-endpoint-microservices you have the endpoint needed.

Hitting this endpoint http://localhost:8080/microservices you will get the microservices and nodes availables.

The data is serialized, so you will need fecth the proto files in this endpoint http://localhost:8080/proto/models.

I have to change some implementation details but you can start to work on this with those endpoints.

[calvellido]

To fetch the proto describing metrics structure:
http://localhost:8080/proto/models/metrics

To fetch the proto associated with available nodes:
http://localhost:8080/proto/models/microservices

[calvellido]

In this issue, in the JS code and TS definitions generation step, we can go along with two routes, given that there are two JS runtime Protocol Buffers implementations.

• On release 3.0.0, starting 2016, Google added node/JS support to its official google-protobuf library. TypeScript support is something that was discussed at some degree in the repo issues, and even the team use TS code generation internally, but it's not yet open to the public. For this purpose then, ts-protoc-gen is our very best alternative.

• Protobuf.js is a previous third-party attempt, its origin can be traced up to even March 2013, and included TypeScript support with its full rewritten 6.0.0 release back in November 2016.

Protobufjs	google-protobuf + ts-protoc-gen
Much much better performance, although running the benchmark locally did throw a bit less of a difference on the results, they were still massive.	Performance is somehow constrained by google-protobuf runtime JS implementation, which in the end for encoding/decoding is more or less aligned with that of JSON. An approach with some improvements can be consulted here.
Preserves precision, through the use of a dedicated library, long.js, which addresses this issue by representing a Long as two internal parts of 32 bits each. Only problem being that its use along TypeScript definitions might be a bit convoluted.	Precision could be lost when using [s/u]int64 value types on a proto descriptor, due to the discrepancy between the number type on JavaScript, which is based on the IEEE 754 binary64 format (Double-precision floating-point), hence only values between -(253-1) and 253-1 will be safe. Out of that range (namely values until -(263-1) and 263-1, valid for a int64/long datatype) will be rounded to a near value. Some workaround can be found here, and a discussion and a PR for google-protobuf trying to address this issue is here. Also a solution has been provided in the release 3.4, but this one implies changes to our proto files adding a [jstype = JS_STRING] option to our int64 definitions.
Support for services do exist, though the library make no assumptions on the actual transport channel used, so the user must provide an RPC implementation.	Services have first-class citizen support. The use of gRPC could be easily achieved, thanks to the grpc-web spec and grpc-web-client library, which provides different transport channels depending on the execution context.
For time when not full functionality is needed (statically generated code, JSON reflection) final bundle size can be reduced thanks to some stripped down versions offered.	Final bundle size can take a hit, due to this library most apparently being designed to be used on server side through node.js (browser use was somehow in the team aspirations nevertheless).
Browser compatibility is pretty good, even with the possibility to reach non-ES5 environments using a polyfill.	Again, as it doesn't look like the primary goal of this library is to be used client-side, wide browser compatibility (while maybe not problematic) can't be something taken for granted.

Due to our current target of integrating freestyle-opscenter through RPC, the google-protobuf implementation will be used.

Should any of the advantages offered by the Protobuf.js library become needed to our project, a branch with the needed changes to be able to use Protobuf.js is gonna be set.

---

A more detailed comparison between Protobuf.js and JSON performance can be found here and here, and more tidbits here.