Media Library Config Service

CHALLENGE REQUIREMENTS
We are building a configuration provider (micro) service. This service will consist of two components described below:
(***Note: please register to download the full spec with screenshots from the forum.)

Configuration Provider Microservice (called CPM)
This service consumes a configuration file (JSON) and provides the possibility for other microservices to register themselves in order to retrieve configuration changes. Upon changes, the registered microservices will get informed about the configuration changes by calling an API that is provided by the consuming microservices via the CCNM.
The CPM also provides an API endpoint which can be used by consuming microservices to get configuration upon their initial launch or when informed about a change.

Configuration Consumer Node Module (called CCNM)
This node module will be used by all microservices that want to consume the configuration provided by the CPM. This module exposes an API endpoint on which the CPM is able to inform the consuming microservice about changes and retrieves the configuration from the CPM. It also manages the registration and deregistration of the consuming microservice at the CPM.

Configuration File Description
This file is a JSON file that will be consumed by the CPM. It contains the configuration for all our other microservices. It also contains the configuration for the CPM and CCNM (described as “configuration-provider”)

Example Schema:
{
  "configuration-provider": {
    "registration-interval": 60
    "cleanup-threshold": 120
  },
  "microservice-number-one": {
    "parameter-one": "value",
    "parameter-two ": "value"
  },
  "microservice-number-two": {
    "parameter-one": "value",
    "parameter-two ": "value"
  }
}

Consumer Registration Directory Description
This directory contains a lockfile for each consuming microservice that has registered itself at the CPM. A typical consuming microservice lock file has the following name and contains information about the endpoint provided by the CCNM.
 
Example Lockfile Name:
microservice-number-one.<host>.<registration-timestamp>
 
The lockfiles are created by the CPM when a consuming microservice is being registered. The timestamp in the filename defines, when the consuming microservice has been registered last time.
 
A consuming microservice has to re-register itself in a certain interval. The timestamp of the lockfile will be update on re-registration.
 
The lockfiles are removed when either a consuming microservice is deregistering itself, when the timestamp of a lockfile is older than a certain threshold (set by “cleanup-threshold” in configuration).
 
Configuration Provider Microservice Description
The CPM REST API listens on port 80 (port should be configurable).
 
The CPM is providing a REST API to retrieve the configuration for consuming microservices with the following endpoint:

• GET /configuration
  • Parameters:
    • service: name of calling consumer microservice
  • Return:
    • configuration as JSON, this will return the whole configuration regardless of the service name.

The CPM is providing an API to register and deregister consuming microservices with the following endpoints:

• POST /consumers/register
  • Parameters:
    • service: name of calling consumer microservice
    • host: hostname or ip of consuming microservice
  • Return:
    • JSON Response with configured registration-interval
• POST /consumers/deregister
  • Parameters:
    • service: name of calling consumer microservice
    • host: hostname or ip of consuming microservice
  • Return
    • 200 OK

Each microservice that wants to consume the configuration needs to register itself in order to get informed about updates.
 
The CPM will create a lockfile in a directory for each consuming microservice that registers itself. The structure of a lockfile is described in “Consumer Registration Directory Description”.
 
The CPM will remove the lockfile for a consuming service in the following cases:

• A consuming service calls the deregister REST API endpoint
• A consuming service does not answer a notification API call (timeout)
• The lockfile of a consuming service is older than what is configured as the “cleanup-threshold”

 
If the configuration file is changed, the CPM needs to notice this and notify all registered consuming microservices that there is a change in the configuration (calling the REST API provided by the CCNM inside the consuming microservices).

If the service starts for the first time, it will inform every consuming microservice to ensure the application of possible changes between last stop and start of CPM.
 
The CPM will read in the configuration file upon start and keep it in memory.
All requests of the configuration from consuming microservices will be fulfilled with the configuration in memory for optimal performance.
If the file changes, the in memory configuration will be updated.
 
Configuration Consumer Node Module

• The CCNM is used by consuming microservices to get notified about configuration changes and to retrieve the configuration provided by the CPM.
• The CCNM must be a singleton.
• The CCNM must have an init function.
• The CCNM exposes a config object in every file it is being imported.
• The CCNM exposes a function to register at the CPM for notifications about configuration changes.
• The CCNM exposes a function to deregister at the CPM.
• The address of the CPM is handed over to the CCNM upon initialization.
• The CCNM exposes a function that triggers the retrieval of the current configuration from the CPM and replaces the configuration object with the new configuration. If this is not successful, the CCNM must throw an error on which can be caught by the consuming microservice.
• The CCNM exposes a listener / event trigger that will be triggered, when a configuration change has happened. The consuming microservice can listen to the change event and implement a custom function, that is executed on a configuration change.

In order to retrieve a notification by the CPM about a configuration change, the CCNM must provide a REST API that is listening on port 1337 (port should be configurable). This API must implement the following endpoint:

• GET /configuration/notify
  • Empty payload.
  • No parameters.
  • Returns 200 OK

TECH REQUIREMENTS

• Programming language used must be node.js written in typescript.
• The provided project skeleton must be used for implementation
• Code must be properly documented
• The provided linting configuration must be used
• Every implemented functionality must be tested by unit-tests
• All packages used for this implementation must be MIT, BSD or Apache 2.0
• Every defined port, host etc. should be put in central variables / configurations for easy re-configuration (if applicable).
• The express based components of this implementation must be based on https://tsed.io/

EXPECTED RESULT 

• Configuration Provider Microservice (CPM) including:
  • Exposes a consumer registration / deregistration REST API
  • Exposes a configuration retrieval REST API
  • Configuration change notification to REST API of all consuming microservices
  • File based configuration on which changes are detected during runtime
• Configuration Consumer Node Module (CCNM) including:
  • Exposes a configuration object
  • Exposes a configuration change notification REST API
  • Exposes function / listener to trigger action when receiving a notification
  • Exposes a function to trigger retrieval of the current configuration from the CPM
• All REST APIs must provide proper HTTP Error Codes
• Unit Tests for testing of the implementation needs to be provided
• Package.json must be tidied up and only contain used dependencies
• Package.json must distinct between development and production dependencies

Final Submission Guidelines

• A single zip file containning full source code that covers all the mentioned requirements, including unit tests
• There must be a detailed readme file in markdown format containing details on how to configure, run and verify the submission.
• A video based verification is NOT acceptable.