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

@elvenspellmaker/node-service-status

v0.0.11

Published

A package to provide a Service Status functionality for Node.js projects.

Downloads

14

Readme

Node Service Status Build Status npm version

This library provides a mechanism to generate an object from a list of service status monitors and provdies the ability to either run all monitors or just one.

Requirements

A modern Node that understands classes and async/await.

Usage

npm install --save @elvenspellmaker/node-service-status

Then define a monitor, create a class extending the ServiceStatusMonitor class, making sure to override both the name() and run() methods. Note: run() may be an async method returning a Promise, however name() should NOT be.

"use strict";

const ServiceStatusMonitor = require('@elvenspellmaker/node-service-status').ServiceStatusMonitor;

class DbCanConnectMonitor extends ServiceStatusMonitor
{
	// Some constructor taking in a db

	name()
	{
		return 'db-can-connect';
	}

	async run()
	{
		return await this.db.auth();
	}
}

Monitors should return Boolean true if successful and any other value if unsuccessful. Promises will be resolved and unpacked to see if the value is Boolean true.

In order to consume service status monitors, create an instance of ServiceStatus and pass in an array of monitors.

const ServiceStatus = require('@elvenspellmaker/node-service-status').ServiceStatus;
const DbCanConnectMonitor = require('../monitor/DbCanConnectMonitor');

const ss = new ServiceStatus([
	new DbCanConnectMonitor(db),
]);

Then by calling runMonitors() or runMonitor(monitorName) you may run all monitors or a single monitor. The returned object will either be a single status object or an object containing all the statuses and the overall status. Both object types have a top-level parameter successful which gives the overall success of the monitors. For example as JSON:

{
	"successful": false,
	"monitors": [
		{
			"successful": true,
			"monitorName": "true-monitor"
		},
		{
			"successful": false,
			"monitorName": "false-monitor"
		}
	]
}

or

{
	"successful": false,
	"monitorName": "false-monitor"
}

If calling the runMonitors() method, all monitors will be run and will resolve eventually and so the method must be awaited if the value is wanted, such as to output from a route:

const ssResult = await ss.runMonitors();

If calling the runMonitor() method and the passed monitor name is not found, null will be returned which indicates that the monitor does not exist. It is suggested this would be treated as a 404 by your application.

If calling either method and the top-level successful key is false this means one or more of the monitors has failed and it is suggested this is treated as a 503 by your application as the service is broken in some way.

If calling either method and the top-level successful key is true all monitors passed and it is suggested that this would be treated as a 200 by your application.

Notes

  1. Name should NOT be async, and should return a string. If the name method is is missing then a name will be generated in the form of missing-name-<<number>> where missing number is incremented for each monitor with a missing name, and this monitor will always return false to indicate failure.
  2. With the default logger, when NODE_ENV environment variable is set, any Errors will be console logged and the service status will continue as gracefully as possible. In all other environments any Errors will be thrown as Errors for easier debugging.