@sourceloop/feature-toggle-service
v4.0.1
Published
A service that provides feature toggle functionality
Downloads
1,195
Readme
@sourceloop/feature-toggle-service
Overview
Microservice that provides functionality to maintain feature flags at various levels. Initial support for system level, tenant level and user level is provided.
Working and Flow
This service provides CRUD APIs to insert values into the feature-toggle specific data tables that can be read while making the decision if a particular feature is allowed or not to the user. This feature is an extension of the feature-toggle package -- @sourceloop/feature-toggle that provides a method level decorator which will check if that particular API is accessible or not.
Initial implementation for system level, tenant level and user level feature flag is provided.
Installation
npm i @sourceloop/feature-toggle-service
Usage
- Create a new Loopback4 Application (If you don't have one already) lb4 testapp
- Install the service - npm i @sourceloop/feature-toggle-service
- Set up the environment variables
- Run the migrations. (this will create respective tables in your Database)
- Add the
FeatureToggleServiceComponent
to your Loopback4 Application (inapplication.ts
).// import the FeatureToggleServiceComponent import {FeatureToggleServiceComponent} from '@sourceloop/feature-toggle-service'; // add controllers to your application (optional) this.bind(FeatureToggleBindings.Config).to({ bindControllers: true, useCustomSequence: false, }); // add Component for FeatureToggleService this.component(FeatureToggleServiceComponent);
- Set up a Loopback4 Datasource with
dataSourceName
property set toFeatureToggleDbName
. You can see an example datasource here. - Start the application
npm start
Asymmetric Token Signing and Verification
If you are using asymmetric token signing and verification, you need to create a datasource for auth database. Example datasource file for auth:-
import {inject, lifeCycleObserver, LifeCycleObserver} from '@loopback/core';
import {juggler} from '@loopback/repository';
import {AuthDbSourceName} from '@sourceloop/core';
const DEFAULT_MAX_CONNECTIONS = 25;
const DEFAULT_DB_IDLE_TIMEOUT_MILLIS = 60000;
const DEFAULT_DB_CONNECTION_TIMEOUT_MILLIS = 2000;
const config = {
name: 'auth',
connector: 'postgresql',
host: process.env.DB_HOST,
port: process.env.DB_PORT,
user: process.env.DB_USER,
schema: process.env.DB_SCHEMA,
password: process.env.DB_PASSWORD,
database: process.env.AUTH_DB,
};
// Observe application's life cycle to disconnect the datasource when
// application is stopped. This allows the application to be shut down
// gracefully. The `stop()` method is inherited from `juggler.DataSource`.
// Learn more at https://loopback.io/doc/en/lb4/Life-cycle.html
@lifeCycleObserver('datasource')
export class AuthDataSource
extends juggler.DataSource
implements LifeCycleObserver
{
static dataSourceName = AuthDbSourceName;
static readonly defaultConfig = config;
constructor(
@inject('datasources.config.auth', {optional: true})
dsConfig: object = config,
) {
if (!!+(process.env.ENABLE_DB_CONNECTION_POOLING ?? 0)) {
const dbPool = {
max: +(process.env.DB_MAX_CONNECTIONS ?? DEFAULT_MAX_CONNECTIONS),
idleTimeoutMillis: +(
process.env.DB_IDLE_TIMEOUT_MILLIS ?? DEFAULT_DB_IDLE_TIMEOUT_MILLIS
),
connectionTimeoutMillis: +(
process.env.DB_CONNECTION_TIMEOUT_MILLIS ??
DEFAULT_DB_CONNECTION_TIMEOUT_MILLIS
),
};
dsConfig = {...dsConfig, ...dbPool};
}
super(dsConfig);
}
}
Environment Variables
| Name | Required | Default Value | Description |
| ------------- | -------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| NODE_ENV
| Y | | Node environment value, i.e. dev
, test
, prod
|
| LOG_LEVEL
| Y | | Log level value, i.e. error
, warn
, info
, verbose
, debug
|
| DB_HOST
| Y | | Hostname for the database server. |
| DB_PORT
| Y | | Port for the database server. |
| DB_USER
| Y | | User for the database. |
| DB_PASSWORD
| Y | | Password for the database user. |
| DB_DATABASE
| Y | | Database to connect to on the database server. |
| DB_SCHEMA
| Y | | Database schema used for the data source. In PostgreSQL, this will be public
unless a schema is made explicitly for the service. |
| JWT_SECRET
| Y | | Symmetric signing key of the JWT token. |
| JWT_ISSUER
| Y | | Issuer of the JWT token. |
Setting up a DataSource
Here is a sample Implementation DataSource
implementation using environment variables and PostgreSQL as the data source.
import {inject, lifeCycleObserver, LifeCycleObserver} from '@loopback/core';
import {juggler} from '@loopback/repository';
import {FeatureToggleDbName} from '@sourceloop/feature-toggle-service';
const config = {
name: FeatureToggleDbName,
connector: 'postgresql',
url: '',
host: process.env.DB_HOST,
port: process.env.DB_PORT,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
database: process.env.DB_DATABASE,
schema: process.env.DB_SCHEMA,
};
@lifeCycleObserver('datasource')
export class FeatureToggleDbDataSource
extends juggler.DataSource
implements LifeCycleObserver
{
static dataSourceName = FeatureToggleDbName;
static readonly defaultConfig = config;
constructor(
@inject('datasources.config.feature', {optional: true})
dsConfig: object = config,
) {
super(dsConfig);
}
}
Migrations
The migrations required for this service are processed during the installation automatically if you set the FEATURETOGGLE_MIGRATION
or SOURCELOOP_MIGRATION
env variable. The migrations use db-migrate
with db-migrate-pg
driver for migrations, so you will have to install these packages to use auto-migration. Please note that if you are using some pre-existing migrations or database, they may be effected. In such scenario, it is advised that you copy the migration files in your project root, using the FEATURETOGGLE_MIGRATION_COPY
or SOURCELOOP_MIGRATION_COPY
env variables. You can customize or cherry-pick the migrations in the copied files according to your specific requirements and then apply them to the DB.
This migration script supports both MySQL and PostgreSQL databases, controlled by environment variables. By setting MYSQL_MIGRATION to 'true', the script runs migrations using MySQL configuration files; otherwise, it defaults to PostgreSQL. .
Additionally, there is now an option to choose between SQL migration or PostgreSQL migration.
NOTE : For @sourceloop/cli
users, this choice can be specified during the scaffolding process by selecting the "type of datasource" option.
API Documentation
Common Headers
Authorization: Bearer where is a JWT token signed using JWT issuer and secret.
Content-Type: application/json
in the response and in request if the API method is NOT GET
Common Request path Parameters
{version}: Defines the API Version
Common Responses
200: Successful Response. Response body varies w.r.t API 401: Unauthorized: The JWT token is missing or invalid 403: Forbidden : Not allowed to execute the concerned API 404: Entity Not Found 400: Bad Request (Error message varies w.r.t API) 201: No content: Empty Response
API Details
Visit the OpenAPI spec docs