Library for frequently used features by new REST api applications created/deployed.

Installation

$ npm install svm-util

Features

• Loading application configuration
• Logging (util.log)
• Storing/Retrieving (util.execSQL) data from database (pool management + query)
• Calling (util.request) other REST APIs
• Communication (util.email, util.sms) using email and text/sms messages.
• Utility functions that are used frequently

Quick Start

let { App, getApplicationUtility } = require("svm-util");
// pass the application to getApplicationUtility function to get the utility.
let util = getApplicationUtility(App.dd_api);

//use util for logging
let LogLevel = util.LogLevel;
util.log(
  LogLevel.http,
  "svm:svm-test:utils",
  "main",
  null,
  null,
  util.getApplicationConfigLog()
);

//use util for executing datbase statments.
util
  .execSQL("select * from `learn`.`ip`")
  .then((results) => {
    console.log(results);
  })
  .catch((err) => {
    util.log(
      LogLevel.error,
      "svm:svm-test:utils",
      "main",
      null,
      null,
      `Error ${err} occured when querying database.`
    );
  });

Philosophy

The philosophy is to provide common functionality for quickly standing up robust REST api services.

Configuration

In order to use svm-util library, a json configuration file must be created, stored and available on the server where your REST API server is able to read this configuration file. This configuration file is searched in the following order in the file system -

1. Utility was created with application id

getApplicationUtility(App.dd_api)

Configuration file is searched at

• {user_home} + path_sep + apps + path_sep + {app id} + path_sep + config + path_sep + {application}.json

Example : if the application=dd_api, and user's home directory = /home/jenkins and the server is linux based then the configuration file will be read from

/home/jenkings/apps/dd_api/config/dd_api.json

2. Utility was created with application id and application home

getApplicationUtility(App.dd_api,appHome:string)

Configuration file is searched at

• {app_home} + path_sep + apps + path_sep + {app id} + path_sep + config + path_sep + {application}.json

Example : if the application=dd_api, and app_home = /var/temp and the server is linux based then the configuration file will be read from

/var/temp/apps/dd_api/config/dd_api.json

The configuration file is divided into multiple sections. Number of sections may change in the future. However, existing sections will not change during minor and patch releases.

• API_CONFIG : Configuration to be used for the http server for serving REST APIs.
• DOC_CONFIG : Configuration to be used for storing/retrieving documents.
• COMM_CONFIG: Configuration to be used for communication via email and/or phone for messaging.
• LOG_CONFIG : Configuration to be used for logging

An exaple of the configuration file (for application dd_api) is shown below. All items are optional default values will be used if any of these values are missing. Values shown below are expected default values. APP_ID, config file name and location is determined by the rules above.

Even though all items are optional, it is recommended to create this file and override values as per your needs.

Logging.

Logging can be turned on and off at multiple levels -

1. By module : This is done by adding NODE_DEBUG={$pattern} before invoking node to execute your module. Now only those module whose name (pgm_cd) match with the pattern will show up in the log.

2. By LogLevel : Following order of log levels are used : error, warn, info, http, verbose, debug, silly. Here error is the lowest and silly is the highest. In the configuration file, loglevel has to be identified at which logging is needed. If logging is requested at level=info then info and all levels below info(error, warn) will be included as well.

3. By LogMethod: Following methods of logging are supported : CONSOLE, FILE, API and DATABASE. Console is defaulted at level=info. These methods need to be enabled in the config file under LOG_CONFIG section of the file. In order to log in a database, following table must be created ready for use in the schema that you will be utilizing for logging.

CREATE DATABASE IF NOT EXISTS `svayam`;

CREATE OR REPLACE TABLE `svayam`.`svm_app_log` (
`rec_id`            SERIAL,
`app_cd`            VARCHAR(50) NOT NULL,
`pgm_cd`            VARCHAR(50) NOT NULL,
`fn_cd`             VARCHAR(50) NOT NULL,
`act_id`            VARCHAR(50)             DEFAULT NULL,
`log_meta_json`     JSON        NOT NULL    CHECK (JSON_VALID(`log_meta_json`)),
`log_lvl_cd`        VARCHAR(50) NOT NULL,
`log_lvl_num`       TINYINT     AS (CASE
                                        WHEN `log_lvl_cd` = "error"     THEN 0
                                        WHEN `log_lvl_cd` = "warn"      THEN 1
                                        WHEN `log_lvl_cd` = "info"      THEN 2
                                        WHEN `log_lvl_cd` = "http"      THEN 3
                                        WHEN `log_lvl_cd` = "verbose"   THEN 4
                                        WHEN `log_lvl_cd` = "debug"     THEN 5
                                        WHEN `log_lvl_cd` = "silly"     THEN 6
                                        ELSE -1
                                    END) STORED,
`log_msg`           LONGTEXT NOT NULL,
`log_ts`            TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(),
`log_dt`            DATE AS (DATE(`log_ts`)) STORED,
PRIMARY KEY (`rec_id`)      USING BTREE,
INDEX       (`app_cd`)      USING BTREE,
INDEX       (`act_id`)      USING BTREE,
INDEX       (`log_lvl_cd`)  USING BTREE
)
ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


-- Query the log
select `log_ts`, `log_lvl_cd`, `log_lvl_num`, `pgm_cd`, `fn_cd`, `log_msg`, `log_meta_json`
from `avayam`.`svm_app_log`

In order to log in your module, get handle to Application Utility and use the log method. The signature of the log function/method is as following - log(level:logLevelType, pgm_cd:string, fn_cd:string, act_id:number|null, meta:any, msg:string): void

Here -

1. level is required and can be one of the following => "error", "warn", "info", "http", "verbose", "debug", "silly". You can also get a prompt for these using util.LogLevel
2. pgm_cd is optional. Though it is optional, it should generally be provided to know the file from where this log is getting generated. It should be the name of the module (js/ts file)
3. fn_cd is optional. Though it is optional, it should generally be provided to know the location within a file from where this log is getting generated. It is the name of the function/place in module that generated the log message.
4. act_id is optional and represents the account identifier. It should be numeric.
5. meta is optional. If provided, this should be a object definition with keys and values that represents extra information that you would like to log. Example - { extra: "Extra value to be logged"}
6. msg is required and represents the message containing the information that needs to be logged.

let { App, getApplicationUtility } = require("svm-util");
// pass the application to getApplicationUtility function to get the utility.
let util = getApplicationUtility(App.dd_api);

util.log(util.LogLevel.http, "My Module", "My Function", null, { extra: "Extra" }, `Hello Logger...!`);

Contributing

Security Issues

Running Tests

People

The original author is Svayam Infoware Pvt. Ltd.

License

(c) Copyright 2021 - Svayam Infoware Pvt. Ltd., All rights reserved.