0.0.1 • Published 4 years ago

ad2-auth v0.0.1

Weekly downloads
-
License
MIT
Repository
-
Last release
4 years ago

Description

The auth microservice handles user authentication for Waypath, including resetting passwords.

Installation - Global Requirements

npm install -g typescript
npm install -g @nestjs/cli

Note: On Windows computers an additional package needs to be installed to allow environment variables to be set in the same was as on MacOS and Linux computers:

npm install -g win-node-env

Installation

$ npm install

Build

The build process is triggered by the following command. This command processes the TypeScript code into JavaScript, and if no errors occured will create the build output files to the dist/ folder. Those output files are the ones that are then deployed via the CI/CD pipelines.

$ npm run build

Configuration

The configuration files are as follows:

  • dev.env - This contains microservice specific configuration settings for the development environment
  • ormconfig.json - This contains local connection settings and is for local development only. It allows you to generate and run migrations locally or run them against any database depending on the settings in this file
  • (optional) prod.env, demo.env, staging.env, test.env - microservice configuration files depending on the runtime environment
  • AWS parameter store - This is used to get all settings except for the local listen port (at the moment). These settings currently include Auth0 and database connection string settings

The environment specific configuration files (*.env) contains the basic listener settings in a standard text format, as shown below. The dev.env file must be created before the microservice can run.

dev.env example

LISTEN_PORT=8443
SWAGGER_SCHEME=http

ormconfig.json example

{
    "type": "postgres",
    "host": "localhost",
    "port": 5432,
    "username": "agridigital",
    "password": "thepassword",
    "database": "AuthData",
    "entities": [
        "src/**/*.entity{.ts,.js}"
    ],
    "migrationsRun": false,
    "migrations": [
        "src/migrations/**/*.ts"
    ],
    "migrationsTableName": "_migrations",
    "cli": {
        "migrationsDir": "src/migrations"
    },
    "subscribers": [
        "src/subscribers/**/*.ts"
    ],
    "synchronize": false,
    "schema": "dbo"
}

Creating the initial database

You may need to change the username agridigital below to a username with appropriate permissions to create a database on the postgres instance (usually local for development). This will create a new database called DeliveryData, and needs to be run only once. If the psql binary is not in path then it may need to be called with the full path included.

$ psql -U agridigital -d postgres -a -f ./src/sql/db-create.sql 

Running db migrations

The database migrations will create the database tables and other objects required for the deliveries microservice. The migrations engine of TypeORM creates a table to track which migrations have been implemented in the database, in a table called _migrations. The command to run all pending migrations is below.

$ ./node_modules/ts-node/dist/bin.js ./node_modules/typeorm/cli.js migration:run

Generating a new db migration

Once you have made changes to the entity classes you can generate a new TypeORM migration using the following command, where migration-name is the name of the migration you are creating. The migration is created in the src/migrations/ directory.

$ ./node_modules/ts-node/dist/bin.js ./node_modules/typeorm/cli.js migration:generate -n [migration-name]

Reverting a db migration

Database migrations can only be reverted one by one with the current version of TypeORM. The command to do this is below:

$ ./node_modules/ts-node/dist/bin.js ./node_modules/typeorm/cli.js migration:revert

Creating a new empty db migration

If you need to write custom SQL code and do not want to scan for entity changes you can create an empty migration using the command below, where migration-name is the name of the migration you are creating. The migration is created in the src/migrations/ directory.

$ ./node_modules/typeorm/cli.js migration:create -n [migration-name]

Debugging the app

To debug in Visual Studio Code the setting "Auto Attach" for the debugger needs to be ON. In addition a launch config file should not exist. Then the application can be run in debug mode from within the Visual Studio Code terminal. Once running in debug mode use the swagger web interface as per usual and breakpoints will be triggered as expected.

# Debug
$ npm run start:debug

Running the app

Important: To run the app in local mode, where NODE_ENV=local, you need to pay attention to the default settings in config.service.ts and type-orm-config.service.ts. When in local mode the micro-service will attempt to use connection information in these files, rather than use the information from the AWS parameter store. This allows easy local development without having to comment out / uncomment lines of code that are specific to local development, but does assume you have a local PostgreSQL database server as well as a local Redis instance running. Changes to the postgres username or password in type-orm-config.service.ts may still be required.

# local
$ npm run local

# development
$ npm run start

# watch mode
$ npm run start:dev

# production mode
$ npm run start:prod

Linter

$ npm run lint

Tests

# unit tests
$ npm run test

# e2e tests
$ npm run test:e2e

# test coverage
$ npm run test:cov