dominikbraun / dice Goto Github PK

Several test files have to be created for Dice's core functionality. This includes tests for

• the Dice core
• the service registry
• the key-value store

All tests have to be integrated into the CI as well.

The behavior for the scenario that Dice gets started and no config file can be found should be clarified.

According to Dice's principle that the daemon itself requires zero configuration, an empty dice.yml should be created automatically.

The proxy server accepts incoming HTTP requests and looks up the responsible service in the registry. Next up, it should forward the requests from the client to the service and from the service back to the client.

This should be implemented using two io.Write streams.

:-)

Currently, the code base supports multiple algorithms (BalancingMethods):

• LeastConnectionBalancing
• RandomBalancing
• RoundRobinBalancing
• WeightedRoundRobinBalancing

Only the WeightedRoundRobinBalancing is implemented though. We should provide at least 2 algorithms at the beginning.

Dice should provide an installation script that downloads the binaries (Dice core, CLI) and install them properly. Also, we have to provide a .service file for systemd that should be used the by the installer to set up Dice as a systemd service.

The latest binaries will be available in the release section of Dice.

At the moment, a service is identified by its hostname. If a request is sent to Dice, it looks for the actual destination hostname and forwards the request to the particular service. However, this does not handle cases where example.com/api is a different service than example.com.

This needs to be enabled using a 'real' routing system. Services have to be identified by a route, not an hostname, and the proxy has to look for a route in the service registry.

The installation of Dice including the utilization of systemd needs to be clarified and implemented.

There should be some restrictions for configurable entity data. "Configurable entity data" simply is data for nodes, services and instances that can be configured by the user - such as names or URLs.

An example for a restriction might be to disallow whitespaces for names or URLs in the form http://..., since these are node references that will be used in the URL when calling an API endpoint, such as /nodes/my-node-ref/attach. If my-node-ref is an URL with a http:// prefix, the whole thing doesn't work anymore. :)

Validators

Checking these restrictions with simple if conditions is possible, however it would be more elegant to introduce dedicated validator types. A validator knows all business rules and restrictions. The core uses an appropriate validator to check whether a given entity property - when creating the entity - is valid.