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

serviced

v2.0.6

Published

Microservice dependency readiness probe

Downloads

5

Readme

Serviced

Build Status Coverage Status Dependency Status npm version

Microservice dependency readiness probe

Small utility to probe for backing-service availability using http calls and promises. This will likely evolve to be more compatible but, for now, it uses features available in Node 6+. Feel free to send pull requests or open issues to make it compatible with earlier versions.

Motivation

When working with microservices, we often find we need to be prepared for variable times in backing service availability. Most times these are available and ready before we even probe them but some times they are not like in the case of a service needing to apply some configuration specific to a consuming service, etc. Serviced provides a way to probe multiple services with varying probe and retry configurations wrapped in a promise so you can, for example, not start an API server until all its backing services are available and ready.

Usage

npm i serviced

Test that a single service returns status code 200.

const Serviced = require('serviced');

new Serviced('http://exmample.com').then(() => {
  // Your service is online and returns status code 200.
});

Test that multiple services return status code 200.

new Serviced('http://svc-a.com', 'http://svc-b.com').then(() => {
  // Both services are online and return status codes 200.
});

Test the response body from a service request with a test function.

new Serviced({
  url: 'http://svc-a.com',
  test(body) {
    return body.foo === true;
  },
}).then(() => {
  // Service is online and response passes supplied test.
});

Test the response body from multiple service requests with test functions.

new Serviced({
  url: 'http://svc-a.com',
  test(body) {
    return body.foo === true;
  },
}, {
  url: 'http://svc-b.com',
  test(body) {
    return body.bar === true;
  },
}).then(() => {
  // Services are online and responses pass supplied tests.
});

Different options for multiple services.

// http://svc-a.com is only tested for a 200 response.
// http://svc-b.com's response body is passed to your own test function.
new Serviced('http://svc-a.com', {
  url: 'http://svc-b.com',
  test(body) {
    return body.bar === true;
  },
}).then(() => {
  // Services are online and responses pass supplied tests.
});

Pass additional options to underlying request and retry modules.

The optional .request and .retry objects are passed through to the request and retry module instances respectively so you can control those as you deem necessary. It's a straight passthrough so please read their docs to find out what options are available for each.

new Serviced({
  url: 'http://svc-a.com',
  request: { // pass options to request
    auth: {
      user: 'username',
      pass: 'password',
    }
  },
  retry: { // pass options to retry
    retries: 2,
    maxTimeout: 2000,
  },
  test(body) {
    return body.foo === true;
  },
}).then(() => {
  // Service is online and response passes supplied test.
});

Contributing

  • Fork the repo.
  • npm i
  • npm start to work on the library. This runs the tests continuously watching for changes but without test output (debug output instead).
  • Make your changes
  • npm t to run the tests with no debug output (tap output instead).
  • npm run cov to run coverage report.
  • npm run linter to run eslint.
  • Submit a PR.

Change log

  • 2.0.0 Breaking changes from 1.x. I switched to retry over backoff primarily because of how it handles errors but also for simplicity.