Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@restorecommerce/chassis-srv

Package Overview
Dependencies
Maintainers
3
Versions
69
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@restorecommerce/chassis-srv

Restore Commerce microservice chassis

  • 0.1.1
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
517
increased by21.65%
Maintainers
3
Weekly downloads
 
Created
Source

= Chassis Service

https://www.npmjs.com/package/@restorecommerce/chassis-srv[image:http://img.shields.io/npm/v/@restorecommerce/chassis-srv.svg?style=flat-square[Version]] https://travis-ci.org/restorecommerce/chassis-srv?branch=master[image:http://img.shields.io/travis/restorecommerce/chassis-srv/master.svg?style=flat-square[Build Status]] https://david-dm.org/restorecommerce/chassis-srv[image:https://img.shields.io/david/restorecommerce/chassis-srv.svg?style=flat-square[Dependencies]] https://coveralls.io/github/restorecommerce/chassis-srv?branch=master[image:http://img.shields.io/coveralls/restorecommerce/chassis-srv/master.svg?style=flat-square[Coverage Status]]

A library for https://github.com/restorecommerce/[Restorecommerce] microservices.

[#features] == Features

  • Business logic exposed via gRPC
  • Retry and timeout logic
  • Endpoint calls with custom middleware
  • Provide multiple microservice functionality from the Restorecommerce ecosystem, such as logging, database access, cache handling or exposing system commands.

[#architecture] == Architecture

The chassis service consists of 8 components:

  • a configuration loader
  • a multi-transport configurable log infrastructure
  • a base Restorecommerce microservice structure provided by the link:src/microservice/server.ts[Server] class, which emits state-related events and can be bound to a number of https://grpc.io/docs/[gRPC] endpoints, given a https://developers.google.com/protocol-buffers/docs/overview[Protocol Buffer] interface and a transport config
  • custom middleware
  • a cache-loader based on configuration files
  • a provider-based mechanism to access different databases
  • a base implementation for a link:./docs/modules/ROOT/pages/command-interface.adoc[command-interface]
  • periodic storage for https://kafka.apache.org/[Apache Kafka] topic offsets

[#configuration] == Configuration

Configs are loaded using the https://github.com/indexzero/nconf[nconf]-based module https://github.com/restorecommerce/service-config[service-config]. Such configuration files may contain endpoint specifications along with their associated transports or simple access configs for backing services such as a database or even a Kafka instance. To remove the buffered data from being logged link:./test/cfg/config.json[bufferedFields] configuration can be set.

[#configuration_logging] === Logging

Logging functionality is provided through https://github.com/restorecommerce/logger[logger], which uses https://github.com/winstonjs/winston[winston]. Logger output transport, severity levels and other options are configurable.

Default logging levels are:

  • silly
  • verbose
  • debug
  • info
  • warn
  • error

[#configuration_server] === Server

A link:src/microservice/server.ts[Server] instance can provide multiple service endpoints and emits events related with the microservice's state. An endpoint is a wrapped gRPC method accessible from any gRPC clients. It is also possible to configure the Server with number of times a request should be link:./test/microservice_test.ts[retried and timeout configurations]. Service responses always include a result or an error. When a Server is instantiated, it is possible to bind one or more services to it, each of them exposing its own RPC endpoints with an associated transport configuration (port, protobuf interfaces, service name, etc). Note that other transport types beside gRPC are theoretically possible, although that would require an extension of the Server class with a custom transport config.

[#configuration_middleware] === Middleware

Endpoint calls may be intercepted with any number of link:./test/middleware_test.ts[custom chained middlewares]. The request traverses the middleware before reaching the service function. The middleware can call the next middleware until the last middleware calls the service function.

[#configuration_cache] === Cache

Multiple cache providers can be registered and loaded within a microservice. Such providers are managed with https://github.com/BryanDonovan/node-cache-manager[node-cache-manager].

[#configuration_database] === Database

The following database providers are implemented:

Providers include generic database handling operations (find, insert, upsert delete, truncate, etc). Query parameter structure for all exposed operations is similar with the structure used in https://docs.mongodb.com/manual/tutorial/getting-started/[MongoDB] queries. The ArangoDB provider supports graph database creation and exposes a simple API to manage vertices and edges. It also provides a flexible traversal method. For more details, see link:test/graphs_test.ts[graph tests] and the https://docs.arangodb.com/3.3/HTTP/Gharial/[ArangoDB graphs documentation]. Database providers can be used as a database abstraction by any service that owns a set of resources. Furthermore, services can later expose their database operations via gRPC. Exposure of these operations is easily achieved using the https://github.com/restorecommerce/resource-base-interface[resource-base-interface].

[#configuration_command_interface] === Command Interface

An interface for system commands (useful information retrieval, system control, etc) is also provided. For more details about all implemented operations please refer link:./docs/modules/ROOT/pages/command-interface.adoc[command-interface]. This interface can be directly exposed as a gRPC endpoint and it can be extended by a microservice for custom functionality.

[#configuration_offset_store] === Offset Store

This stores the offset values for each Kafka topic within each microservice at a fixed interval to a https://redis.io/[Redis] database. Such intervals are configurable through the offsetStoreInterval configuration value. The offset values are stored with key {kafka:clientId}:{topicName}. In case of a service failure, a microservice can then read the last offset it stored before crashing and thus consume all pending messages since that moment. This feature can be disabled if the latestOffset configuration value is set to true - in this case, the service subscribes to the latest topic offset value upon system restart.

Keywords

FAQs

Package last updated on 21 Jul 2020

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc