Gateway-challenge

API REST service (JSON/HTTP) for storing information about gateways and their associated devices.

Table of contents

• Gateway-challenge
  • Table of contents
  • Installing
  • Basic Usage
  • Features
  • Environments
  • API docs
    • Devices
    • Routes
  • Next versions

Installing

$ npm install gateway-challenge

$ npm install @types/gateway-challenge

The design trusts on environment variables to customize its performace based on the present use case. See environments section for further details.

Basic Usage

  import { startGatewayService } from 'gateway-challenge';

  const server = startGatewayService(3000); // SERVER-PORT.

Features

• CRUD operations coverage.
• Structure by technical responsabilities.
• Monolith design.
• Extensible test environments.
• API routes prefix.

Environments

Based on the present requirements, the service defines the following custom environments, test and development, yet its components and design are intented to extend these ones if required.

• By default, production environment is used, this one trusts on DB_PROD_HOST, DB_PROD_PORT, DB_PROD_NAME, DB_PROD_USER and DB_PROD_PASSWORD as its environment variables.

To run a development environment, first install the dependencies, then run npm run dev:

$ npm install
$ npm run dev

This one trusts on DB_DEV_HOST, DB_DEV_PORT, DB_DEV_NAME, DB_DEV_USER and DB_DEV_PASSWORD as its environment variables.

To run the test suite, first install the dependencies, then run npm test:

$ npm install
$ npm test

This one trusts on DB_TEST_HOST, DB_TEST_PORT and DB_TEST_NAME as its environment variables.

API docs

Devices

The service supports device-like structures to shape real devices throughout its components and make them more human-readable to maintenance and contribution concerns.

Parent devices, gateway-like structure.

  {
    'identifier': String,
    'name': String,
    'ipv4': String,
    'peripherals': [ associates ]
  }

Associated devices, peripheral-like structure.

  {
    'uid': Number, 
    'vendor': String,
    'date': Date,
    'status': Boolean
  }

Routes

It is intented to use /api/[version] as API routes prefix. Use the following as an example.

[URL]/api/1.0/[route-to-resource]

The service covers up the C.R.U.D operations through the routes defined as the following :

Create as the C in C.R.U.D

POST -> [URL]/api/api-version-available/gateway - Gateway creation.

POST -> [URL]/api/api-version-available/gateway/gateway-identifier/ - Peripheral creation.

The body in the request contains the device properties to shape the device.

Read as the R in C.R.U.D

GET <- [URL]/api/api-version-available/gateway/gateway-identifier/ - Gateway specification.

GET <- [URL]/api/api-version-available/gateway/gateway-identifier/peripheral-uid - Peripheral specificacion.

Or also, retrieve all the existing ones :

GET <- [URL]/api/api-version-available/gateway/all - Retrieve all the gateway specification.

GET <- [URL]/api/api-version-available/gateway/gateway-identifier/all - Retrieve all the peripheral specification.

Update as the U in C.R.U.D

PUT -> [URL]/api/api-version-available/gateway/gateway-identifier/ - Gateway update.

PUT -> [URL]/api/api-version-available/gateway/gateway-identifier/peripheral-uid - Peripheral update.

The body in the request contains the device properties to be modified from the device. Use the following as an example.

  {
    'identifier': 'GT01', // gateway identifier. 
    'uid': 200, // associated device uid.
      'properties': { // properties to be modified.
          'uid': 400,
          'status': false
    }
  }

Delete as the D in C.R.U.D

DELETE -> [URL]/api/api-version-available/gateway/gateway-identifier/ - Gateway deletion.

DELETE -> [URL]/api/api-version-available/gateway/gateway-identifier/peripheral-uid - Peripheral deletion.

Next versions

Since over time the demand of services should increase, the API components was intented to be extensible and reusable for the next versions not interrupting the previous ones performance.

Below are listed the desired features to be included in next designs :

• Load Balance.
• Security concerns.
• Custom and extensible error handling.
• User-roles management.
• Administration user interface.
• Middleware-based validation, logging and so on.
• Listen to more proccess signals, for instance, uncaughtException, unhandledRejection, SIGTERM and so on.