kiva / aries-key-guardian Goto Github PK

follow the pattern already used in AGA and reporting services

We want to be able to consume a message on a kafka topic that triggers the creation of a wallet and corresponding authentication plugin as if a request had been received on the /v1/escrow/create endpoint. This will help enable bulk wallet creation in the future.

This should result in a separate microservice that runs the kafka consumer and does not run an HTTP server (except for a healthcheck endpoint). We only expect to run this locally for now, so will need updates to docker-compose to run all the various pieces that are necessary to have functioning kafka infrastructure. Ultimately, it will need a new helm deployment in order to be deployed to the dev environment, but that is out of scope for this issue.

Before pushing a new docker image, we should run protocol-integration-tests and make sure they pass. This is a quality check that will prevent us from having bad versions of this repo deployed to dockerhub.

Once this ticket is done, we can update aries-key-guardian to no longer send a separate request to get the best positions on a fingerprint match failure.

Like was done with protocol-gateway, we should remove the use of ts-node from aries-key-guardian. The main reason for this is that it makes testing inconsistent. Additionally, certain features in the protocol-common library depend on reflect-metadata, which depends on code actually being transpiled into javascript.

Add helm charts and update Circle CI config to automatically deploy aries-key-guardian to the dev environment once protocol-integration-tests pass and a new docker image has been pushed to dockerhub.

Because TSLint is now deprecated in favor of ESLint, we should migrate to use ESLint.

We may be able to do this quickly by using https://github.com/typescript-eslint/tslint-to-eslint-config.