nestjs-typeorm-lib v2.0.12

Generic ORM Library

This repository contains

• a Nest.js Object Relational Mapper Library using TypeORM for use with Node.js Lambda functions containing
  • the Data Access Objects: ORM Entities
  • the Data Transfer Objects
  • the Repositories to perform basic operations against the Database
  • additional utility functions
  • the PostgreSQL driver configuration provider

Library

The ORM Library is available on Artifactory under the @org/generic-design-typeorm package name.

Publish

• Library can be published at two levels
  • Locally in .tgz format compressed file (local development)
  • Globally into Artifactory in binary format (global deployment to Jfrog Artifactory)
• Publish Locally in .tgz format compressed file
  • Packageing Nodejs project in .tgz format file $ npm pack
  • A new compressed file is created at root of the project : org-generic-design-typeorm-0.0.1.tgz
  • Steps to Install this custom (.tgz) file inside another project
    • copy and paste <.tgz_file> in parallel to package.json for consumper application
    • $ npm i <.tgz_file> in our case: $ npm i org-generic-design-typeorm-0.0.1.tgz
    • Now you could see a new dependency had been added in your consumer application as - "@org/generic-design-typeorm": "file:org-generic-design-typeorm-0.0.1.tgz"
    • Please use this approach for local testing of libary before actually publishing to Artifactory and then testing it (or else our library will un-necessarily bump the version just for sake of testing).
• Publish Globally into Artifactory
  • Please DO-NOT manually try to publish the library using command $ npm publish (Nevertheless scripts will try to prevent accidental publish)
  • Let us follow Feature Branch WorkFlow Model with PR approach inorder to publish required libary version to Artifactory

Bump Project Version

• Read more here : ./bump-version.md
• Bumping/Increasing version of project means- bumping of 'version' property in package.json file
• Every-time a library is build in CI-CD pipeline, before publish to Artifactory like npm we should bump the version of library in-order to say that - Hey new version of this library is available to all the consumers of this library.
• In package.json you will find this property "version": "X.Y.Z"
  • X :Major Version, bump this up when you have major changes and it is huge discrepancy of changes occurred.
  • Y : Minor Version, bump this up when you have new functionality or enhancement occurred
  • Z : Patch version, bump this up when you have bugs fixed or revert changes on earlier version
  • 
• Approach followed while for this library
  • Before developer pushes his changes to feature branch i.e.- during pre-push hook
    • Bump the version when code is about to be pushed to remote feature branch from local
      • Natively this is provided by npm itself :
        • npm version major
        • npm version minor
        • npm version patch
      • This will auto commit a new commit with default commit message as version of package for ex: If current project version is 1.0.0 and now we run script npm version major then commit message would be 2.0.0 which is ready to be pushed to its feature branch
      • You can also use --no-git-tag-version If you don't wish to auto commit with default commit message but just automatically bump version in package.json, so that you can manually commit this changes with your custom commit message
  • Problem:
    • Multiple push to feature branch will cause multiple & un-necessary bumping of version
    • Very high chances of version conflicts with other team members or even if you are working two simultaneous on two PR's i.e- If multiple people have pull requests at that time, then this creates race-condition on who will win on the conflicting bump number
  • Solutions:
    • Multiple push to feature branch will cause multiple & un-necessary bumping of version:
      • In a team we would follow a norm/pattern/syntax, while creating branch i.e.- | feature branch naming convention | Bump version | | -------------------------------- | --------------------- | | major/ | Bump-up Major version | | minor/ | Bump-up Minor version | | patch/ | Bump-up Patch version | | feature/ | No bumping of version | | hotfix/ | No bumping of version |
      • This will avoid the confusion and thus whenever we want to bump the version only then we use appropriate prefix -> major, minor or patch as stated in above table
    • Very high chances of version conflicts with other team members:
      • Should be resolved within the team and Reviewer must to be Mindful to see if there are any PR with same prefix of major or minor or patch at a given point in time.
• Golden Rules to be followed while bumping a version:
  • Whenever a PR is raised with branch name as : major/, minor/ or patch/ ==> Only include in this PR bumping of version, changelogs. Don't include any functionality changes or bug fixes
  • As a Code Reviewer If you can encounter two PR raised for bumping of version, please discuss within the team and resolve this race-condition
  • Pre-push GitHooks are in Action, So you no need to expicitily bump the version, rather just create the branch name with version that you are interested to bump for ex- If interested to bump 'patch' version then create a branch name with prefix patch/ for ex - patch/test-bump and the push the code. No need to bump version manaually, rather git hooks will do for you.
  • Due to any reason If husky is not working please follow :

    - \$ rm -rf .git/hooks
    - \$ npm uninstall -D husky@4.3.8
    - \$ npm install -D husky@4.3.8

  • Husky requires GIT Version to be >= 2.13.2
  • If still this automation does not work then- direct run the commands
    • npm run bump:major ==> To Bump Major version of Project
    • npm run bump:minor ==> To Bump Minor version of Project
    • npm run bump:patch ==> To Bump Patch version of Project

• NOTE:

  • Please Don't try to by-pass husky or publish/release directly from local, These scripts are used to prevent any accidental push or releases
  • There is no separate step require to enable Git Hooks --> If Husky is installed properly in developers machine.
  • Husky is a 3rd party dependency which enables developer to write git hooks without actually writing the shell scripts under .git/hooks folder, Rather directly write in package.json file and run any js file.

• To Summarize the process of publishing :

  • With husky installed, If developer run locally something like git push origin husky will run the pre-push hook which is now pointing to prepush.js file.
  • If developer is on a patch/major/minor branch it will run prepublish.js which does the npm version bump for me
  • If developer is on any other branch it will just run prepublish.js and do nothing.
  • Which simply means that - As a developer, you should never need to run npm run bump:major unless husky is broken

Setting .npmrc file

• Generate NPM Token
  • Access Tokens (tab)
  • Generate New Token (click)
  • New Access Token - Automation > Generate Token
  • This token can be used now in .npmrc file for key -> _auth:${NPM_USER_AUTH_CREDENTIAL}
  • set this variable in nano ~/.bashrc

To unpublish a package

• npm unpublish -f
• npm unpublish nestjs-typeorm-lib -f

Issue with build -> dist (tsc compiler)

• When build the dist folder using command tsc -p . is very slow to build, If we are publishing lib before this build is completed then partial code-build will be pushed to artifactory
• Run this command step-by-step in sequential order
  • $ npm run prebuild
  • $ npm run compile-tsc
  • $ npm pack

@aws-sdk/client-secrets-manager Dependency

• AWS SDK for JavaScript SecretsManager Client for Node.js, Browser and React Native.
• AWS Secrets Manager provides a service to enable you to store, manage, and retrieve, secrets.
• We recommend you use the AWS SDKs to make programmatic API calls to Secrets Manager
• Secrets Manager API supports GET and POST requests for all actions
• npm install @aws-sdk/client-secrets-manager
• Ref:
  • https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-secrets-manager
  • https://aws.amazon.com/sdk-for-javascript/

Steps to create AWS Secrets Manager in AWS

• login to AWS Console
• AWS Region : US East (Ohio)us-east-2 (Make sure)
• AWS Secrets Manager
• Store a new secret
• Select secret type > Other type of secrets
• (add key:value screte key pairs)
• Secret Name: local/typeorm-lib/postgress
• Configure automatic rotation: Disable automatic rotation
• Using this dependency to fetch your screts from AWS Secrets Manager

const { SecretsManagerClient, GetSecretValueCommand } = require('@aws-sdk/client-secrets-manager');

// a client can be shared by difference commands.
fetchScretesFromScretesManager = async function () {
  console.log('Trying to fetch Your Secrets');
  const client = new SecretsManagerClient({ region: 'us-east-2' });

  const command = new GetSecretValueCommand({
    SecretId: 'local/typeorm-lib/postgress',
  });

  // async/await.
  try {
    // process data.
    const response = await client.send(command);
    const parsedResponse = JSON.parse(response.SecretString);
    console.log(parsedResponse);
  } catch (error) {
    // error handling.
  } finally {
    // finally.
  }
};

fetchScretesFromScretesManager();

• In parsedResponse you have your scretes value, which can be now used to configure your postgress-db

Programmatic usage of Library in Consumer Application

• In app.module.ts Import the DatabaseModule and inject TypeOrmConfigService by providing ther service with useFacotry technqiue as async implementation.
• Don't forget import ConfigModule and make it visible globally.

import {
  DatabaseModule,
  TypeOrmConfigService,
  TypeOrmModule,
  TypeOrmModuleOptions,
} from '@airbus/1t21-capital-design-typeorm';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    TypeOrmModule.forRootAsync({
      imports: [DatabaseModule],
      inject: [TypeOrmConfigService],
      useFactory: async (typeOrmConfigService: TypeOrmConfigService): Promise<TypeOrmModuleOptions> => {
        return await typeOrmConfigService.createTypeOrmOptions();
      },
    }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

• Also in your feature Module, do rightly register the required Repository in TypeOrmModule.forFeature() as per need.

import {
  TypeOrmModule,
  ProjectRepository
} from '@airbus/1t21-capital-design-typeorm';
@Module({
  imports: [
    TypeOrmModule.forFeature([
      ProjectRepository
    ]),
  ],
})
export class FeatureModule

• Also don't forget to mention about db related env-variables inside your environment configuration file in Consumer Application for ex:

PGHOST=127.0.0.1
PGPORT=5432
PGUSER=postgres
PGPASSWORD=root
PGDATABASE=coreelec
PGSCHEMA=capital

Golden Rule(s)

• Don't install any dependencies related to database or ORM like- pg, TypeORM, etc in your Consumer Application. Everything that is essential is already provided by this library @airbus/1t21-capital-design-typeorm check src/index.ts to explore all (In case if you require something which is not present, do raise PR for this Repository :)
• To understand more how exactly this library is consumable you can check the repo - https://github.airbus.corp/Airbus/1t21-capital-design-ingestion
• You Service layer Should always speak with Repositry layer via DTO's but not by Entities. (As entity is meant to map JS Object <--> DB Tables, JS Properties <-> DB Columns, etc..)