npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

api-service-cli

v0.1.9

Published

API services

Downloads

10

Readme

API services

This project is a micro-framework to simplify the creation of policy-driven micro-services based on an annotated OpenAPI specification.

Installation

npm -g api-services-cli

Initialize Project

mkdir my-project
a6s init

This will create two directories config and oasv3.

The config folder contains a YAML file that configures the runtime service and global features (plugins). It may, optionally, include an initial OpenAPI definition.

The oasv3 folder also contains an example YAML file that specifies the OpenAPI v3 resources and the features that they represent.

Additional OpenAPI v3 definition resources can be included in this folder.

Start Services

Once configured (using a6s init or manually), then you can start the API Services:

a6s start

Configuration

a6s reads the configuration (YAML) file to initialize the global features and the default OpenAPI definition.

The command loads it's configuration from the ./config folder. Configurations can be specified in JSON or YAML.

The implementation uses the npm config package

By default, the chassis loads the default.yaml file from the ./config folder.

Then it merges the config file that relates to the current NODE_ENV (or "development" if unset)

Minimal Configuration

Each Chassis must be declared with a name and a port. The simplest configuration would be some YAML like this:

    name: example
    port: 5008

Configuring Features

Feature plugins are installed and initialized when a6s starts.

A useful suite of default plugins are baked-in but new plugins can be developed relatively easily.

To enable a feature, simply configure it using it's registered name:

features:
  payload:
    enabled: true
  openapi:
    enabled: true

The openapi feature is effectively mandatory if OpenAPI definitions are required.

Configuration from Environment

The injection algorithm is simply: remove the prefix, convert to lower case, convert _ to . then treat the result as a JSON path to update the config.

    export APIS_NAME=my-chassis-example
    export APIS_PORT=5005
    export APIS_AUDITOR_ENABLED=true
    export APIS_AUDITOR_FILE_FILENAME=my-chassis.log

At runtime, the chassis will deeply inject the following:

name: "my-chassis-example"
port: 5005
auditor:
    enabled: true
    file:
      filename: "my-chassis.log"

Configuration from external files

This approach allows a standard OpenAPI specification to be reused but augmented with Chassis specific configuration.

It may be used for other purposes - to promote re-use, readability and resilience to change.

If a key ends with the @ symbol - then the value will be used to resolve the values from a File or API.

"openapi@": "./docs/swagger.yaml"
openapi:
  info:
    summary: "My example API"

If a similar key exists - openapi@ and openapi - they are merged.

The remote file from openapi@ is loaded first, then the contents are deep merged with the openapi values.

In this example, the loaded info.summary will be replaced with the inline "My example API".

The merged result is stored into the openapi field in the runtime config.

At runtime, for example in a plugin - the uplifted specification is available as "context.openapi".

Defining Operations

Each resource/method in the OpenAPI specification can (and should) be assigned an operation.

For example:

openapi:
  paths:
    /hello_world:
      get:
        feature
          heartbeat:
            message: hello world

The feature options are augmented at runtime with various parameters, including from the global configuration.

Proxy Feature

The proxy feature will forward requests to a remote target and return the response.

This is used to expose 3rd party endpoints (internal micro-services, cloud providers, etc) as a simple reverse proxy.

/proxy/healthz:
  get:
    summary: Health check via proxy
      feature:
        proxy:
          target: http://localhost:5005/healthz

Advanced proxy options can be found at http-proxy-middleware.

Note: the defaults used by the chassis are different from the http-proxy-middleware implementation:

 ignorePath: true
 pathRewrite: true
 changeOrigin: true
 xfwd: true