Shared-libray NPM

Description and Features

Nest framework TypeScript starter repository. It includes the following:

Warning

Never use --no-verify when committing
Never turn off eslint or prettier rules
Never modify DockerFile and .gitlab-ci.yml files

Requirements

node -v
v14.15.5

Installation

yarn

Running the app

First, copy the .env.example file to .env and fill out your environment variables

yarn start:dev

Running test

# unit tests
$ yarn test

# e2e tests
$ yarn test:e2e

# test coverage
$ yarn test:cov

Generate new project

The template has the ability to generate code automatically, with the "init" generator, the project is cleaned and initialized, and with the "module" generator a new ready folder is created with the basic crud

You can have plenty of ways to run hygen. Pick one of the following:

On macOS and Homebrew:

$ brew tap jondot/tap
$ brew install hygen

Globally with npm (or yarn):

$ npm i -g hygen

Generators

# create seed project
$ hygen init with-prompt

# create a new module
$ hygen module with-prompt

Http response

All endpoints must respond in a standardized way, that is, always with the same structure, in this way, our clients can make global handlers to manipulate the information

On successful example

{
  "data": {
    "nodeVersion": "string",
    "uptime": "number",
    "environment": "string",
    "service": "string",
    "appVersionPackage": "string"
  }
}

Data: contains the entire request response
Error: is a flag that indicates that there was no error

On error example

{
  "error": {
    "message": "string",
    "status": "string",
    "code": "number",
    "details": [
      {
        "columnNumber": "string",
        "lineNumber": "string",
        "fileName": "string",
        "functionName": "string",
        "source": "string"
      }
    ]
  }
}

Message: and it is a humanized message to understand the error
Status: It is extra information that allows to differentiate errors with the same response code, it is optional
Details: is the stack that produced the error (this is only visible in non-productive environments)
Code: is the http response code

Important:

To add the status you must pass an object with the status property, when initializing an error

throw new UnauthorizedException({ status: 'BAD_ROLE' });

Logger service

To create logs and make them visible on the servers you must use the logger service (Pino), the context should always be Class.name:this.function.name

Logger Object

const user = {
  id: '1234',
  roles: ['admin'],
  country: 'CL',
  email: 'test@test.com',
};
this.logger.log({ user }, `${HealthService.name}:${this.getWhoami.name}`);

Logger msg

this.logger.log('get ok', `${HealthService.name}:${this.getOk.name}`);

Logger interpolationValues

this.logger.log(
  `getHealthCheck in version %o`,
  `${HealthService.name}:${this.getHealthCheck.name}`,
  process.version,
);

Git

Hocks

When making a commit, the husky tool analyzes your code and looks for errors of the type eslint and prettier, and then validates the commit message, also validate before doing push push commits

  'pre-commit': 'lint-staged'
  'commit-msg': 'commitlint -E HUSKY_GIT_PARAMS'
  'pre-push': 'yarn test'

Branch names

These are the keywords that are used to create a branch

  'features/HU-ID/feature-description'
  'bugfix/HU-ID/feature-description'
  'hotfix/HU-ID/feature-description'

git-flow

Basic flow of a feature in Git

Git-flow

Prefix

All microservices need a prefix, which will be used by the eks (elastic kubernetes service), to be able to perform the reverse proxy correctly

This configuration is in the main.ts file and is built with the env APP_PREFIX

Health endpoints

Endpoints that must be in all microservices, these are in the folder src/health

Root endpoint

Utility service for EKS (elastic kubernetes service)

{{HOST_BASE_API}}/{{APP_PREFIX}}

Whoami endpoint

Utility service for validate auth logic

{{HOST_BASE_API}}/{{APP_PREFIX}}/whoami

Health endpoint

Utility service to obtain the project environment and its versioning

{{HOST_BASE_API}}/{{APP_PREFIX}}/health

Authentication

We have a centralized authorization server (oauth2) with an API Gateway as a service. The authorization server is invoked with an authorizer lambda and once the client's token has been validated, the request enters the EKS cluster and follows its normal flow, injecting the user's info into the headers

Auth-flow

Authorization

Authorization is based on the user's roles, which are extracted from the headers, these roles have previously programmed rules, these rules are the union of a resource, the type of position and finally the role, for more details read the documentation of accessControll

To configure the module you must go to the src/config/acl folder and inside create your rules

CHANGELOG

See CHANGELOG for more information.

Contributing

You are welcome with this project for contributing, just make a PR.

Authors

Edson Alexander Pérez
Oscar Rubio Martínez