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

systemic

v4.1.2

Published

A minimal dependency injection library for node

Downloads

7,419

Readme

tl;dr

Define the system

const Systemic = require('systemic');
const Config = require('./components/config');
const Logger = require('./components/logger');
const Mongo = require('./components/mongo');

module.exports = () => Systemic()
  .add('config', Config(), { scoped: true })
  .add('logger', Logger()).dependsOn('config')
  .add('mongo.primary', Mongo()).dependsOn('config', 'logger')
  .add('mongo.secondary', Mongo()).dependsOn('config', 'logger');

Run the system

const System = require('./system');

const events = { SIGTERM: 0, SIGINT: 0, unhandledRejection: 1, error: 1 };

async function start() {
  const system = System();
  const { config, mongo, logger } = await system.start();

  console.log('System has started. Press CTRL+C to stop');

  Object.keys(events).forEach((name) => {
    process.on(name, async () => {
      await system.stop();
      console.log('System has stopped');
      process.exit(events[name]);
    });
  });
}

start();

See the examples for mode details and don't miss the section on bootstrapping for how to organise large projects.

Why Use Dependency Injection With Node.js?

Node.js applications tend to be small and have few layers than applications developed in other languages such as Java. This reduces the benefit of dependency injection, which encouraged the Single Responsibility Principle, discouraged God Objects and facilitated unit testing through test doubles.

We've found that when writing microservices the life cycle of an application and its dependencies is a nuisance to manage over and over again. We wanted a way to consistently express that our service should establish database connections before listening for http requests, and shutdown those connections only after it had stopped listening. We found that before doing anything we need to load config from remote sources, and configure loggers. This is why we use DI.

Our first attempt at a dependency injection framework was Electrician. It served it's purpose well, but the API had a couple of limitations that we wanted to fix. This would have required a backwards incompatible change, so instead we decided to write a new DI library - Systemic.

Concepts

Systemic has 4 main concepts

  1. Systems
  2. Runners
  3. Components
  4. Dependencies

Systems

You add components and their dependencies to a system. When you start the system, systemic iterates through all the components, starting them in the order derived from the dependency graph. When you stop the system, systemic iterates through all the components stopping them in the reverse order.

const Systemic = require('systemic');
const Config = require('./components/config');
const Logger = require('./components/logger');
const Mongo = require('./components/mongo');

async function init() {
  const system = Systemic()
    .add('config', Config(), { scoped: true })
    .add('logger', Logger())
    .dependsOn('config')
    .add('mongo.primary', Mongo())
    .dependsOn('config', 'logger')
    .add('mongo.secondary', Mongo())
    .dependsOn('config', 'logger');

  const { config, mongo, logger } = await system.start();

  console.log('System has started. Press CTRL+C to stop');

  Object.keys(events).forEach((name) => {
    process.on(name, async () => {
      await system.stop();
      console.log('System has stopped');
      process.exit(events[name]);
    });
  });
}

init();

System life cycle functions (start, stop, restart) return a promise, but can also take callbacks.

Runners

While not shown in the above examples we usually separate the system definition from system start. This is important for testing since you often want to make changes to the system definition (e.g. replacing components with stubs), before starting the system. By wrapping the system definition in a function you create a new system in each of your tests.

// system.js
module.exports = () => Systemic().add('config', Config()).add('logger', Logger()).dependsOn('config').add('mongo', Mongo()).dependsOn('config', 'logger');
// index.js
const System = require('./system');

const events = { SIGTERM: 0, SIGINT: 0, unhandledRejection: 1, error: 1 };

async function start() {
  const system = System();
  const { config, mongo, logger } = await system.start();

  console.log('System has started. Press CTRL+C to stop');

  Object.keys(events).forEach((name) => {
    process.on(name, async () => {
      await system.stop();
      console.log('System has stopped');
      process.exit(events[name]);
    });
  });
}

start();

There are some out of the box runners we can be used in your applications or as a reference for your own custom runner

  1. Service Runner
  2. Domain Runner

Components

A component is an object with optional asynchronous start and stop functions. The start function should yield the underlying resource after it has been started. e.g.

module.exports = () => {
  let db;

  async function start(dependencies) {
    db = await MongoClient.connect('mongo://localhost/example');
    return db;
  }

  async function stop() {
    return db.close();
  }

  return {
    start: start,
    stop: stop,
  };
};

The components stop function is useful for when you want to disconnect from an external service or release some other kind of resource. The start and stop functions support both promises and callbacks (not shown)

There are out of the box components for express, mongodb, redis, postgres and rabbitmq.

Dependencies

A component's dependencies must be registered with the system

const Systemic = require('systemic');
const Config = require('./components/config');
const Logger = require('./components/logger');
const Mongo = require('./components/mongo');

module.exports = () => Systemic()
  .add('config', Config())
  .add('logger', Logger())
  .dependsOn('config')
  .add('mongo', Mongo())
  .dependsOn('config', 'logger');

The components dependencies are injected via it's start function

async function start({ config }) {
  db = await MongoClient.connect(config.url);
  return db;
}

Mapping dependencies

You can rename dependencies passed to a components start function by specifying a mapping object instead of a simple string

module.exports = () => Systemic()
  .add('config', Config())
  .add('mongo', Mongo())
  .dependsOn({ component: 'config', destination: 'options' });

If you want to inject a property or subdocument of the dependency thing you can also express this with a dependency mapping

module.exports = () => Systemic()
  .add('config', Config())
  .add('mongo', Mongo())
  .dependsOn({ component: 'config', source: 'config.mongo' });

Now config.mongo will be injected as config instead of the entire configuration object

Scoped Dependencies

Injecting a sub document from a json configuration file is such a common use case, you can enable this behaviour automatically by 'scoping' the component. The following code is equivalent to that above

module.exports = () => Systemic()
  .add('config', Config(), { scoped: true })
  .add('mongo', Mongo())
  .dependsOn('config');

Optional Dependencies

By default an error is thrown if a dependency is not available on system start. Sometimes a component might have an optional dependency on a component they may or may not be available in the system, typically when using subsystems. In this situation a dependency can be marked as optional.

module.exports = () => Systemic()
  .add('app', app())
  .add('server', server())
  .dependsOn('app', { component: 'routes', optional: true });

Overriding Components

Attempting to add the same component twice will result in an error, but sometimes you need to replace existing components with test doubles. Under such circumstances use set instead of add

const System = require('../lib/system');
const stub = require('./stubs/store');

let testSystem;

before(async () => {
  testSystem = System().set('store', stub);
  await testSystem.start();
});

after(async () => {
  await testSystem.stop();
});

Removing Components

Removing components during tests can decrease startup time

const System = require('../lib/system');

let testSystem;

before(async () => {
  testSystem = System().remove('server');
  await testSystem.start();
});

after(async () => {
  await testSystem.stop();
});

Including components from another system

You can simplify large systems by breaking them up into smaller ones, then including their component definitions into the main system.

// db-system.js
const Systemic = require('systemic');
const Mongo = require('./components/mongo');

module.exports = () => Systemic()
  .add('mongo', Mongo())
  .dependsOn('config', 'logger');
// system.js
const Systemic = require('systemic');
const UtilSystem = require('./lib/util/system');
const WebSystem = require('./lib/web/system');
const DbSystem = require('./lib/db/system');

module.exports = () => Systemic().include(UtilSystem()).include(WebSystem()).include(DbSystem());

Grouping components

Sometimes it's convenient to depend on a group of components. e.g.

module.exports = () => Systemic()
  .add('app', app())
  .add('routes.admin', adminRoutes())
  .dependsOn('app')
  .add('routes.api', apiRoutes())
  .dependsOn('app')
  .add('routes')
  .dependsOn('routes.admin', 'routes.api')
  .add('server')
  .dependsOn('app', 'routes');

The above example will create a component 'routes', which will depend on routes.admin and routes.api and be injected as

 {
  routes: {
    admin: { ... },
    adpi: { ... }
  }
 }

Bootstrapping components

The dependency graph for a medium size project can grow quickly leading to a large system definition. To simplify this you can bootstrap components from a specified directory, where each folder in the directory includes an index.js which defines a sub system. e.g.

<!-- prettier-ignore-end -->
lib/
  |- system.js
  |- components/
      |- config/
         |- index.js
      |- logging/
         |- index.js
      |- express/
         |- index.js
      |- routes/
         |- admin-routes.js
         |- api-routes.js
         |- index.js
// system.js
const Systemic = require('systemic');
const path = require('path');

module.exports = () => Systemic()
  .bootstrap(path.join(__dirname, 'components'));
// components/routes/index.js
const Systemic = require('systemic');
const adminRoutes = require('./admin-routes');
const apiRoutes = require('./api-routes');

module.exports = () => Systemic()
  .add('routes.admin', adminRoutes())
  .dependsOn('app')
  .add('routes.api', apiRoutes())
  .dependsOn('app', 'mongodb')
  .add('routes')
  .dependsOn('routes.admin', 'routes.api');

Debugging

You can debug systemic by setting the DEBUG environment variable to systemic:*. Naming your systems will make reading the debug output easier when you have more than one.

// system.js
const Systemic = require('systemic');
const path = require('path');

module.exports = () => Systemic({ name: 'server' })
  .bootstrap(path.join(__dirname, 'components'));
// components/routes/index.js
import Systemic from 'systemic';
import adminRoutes from './admin-routes';
import apiRoutes from './api-routes';

export default Systemic({ name: 'routes' })
  .add('routes.admin', adminRoutes())
  .add('routes.api', apiRoutes())
  .add('routes')
  .dependsOn('routes.admin', 'routes.api');
DEBUG='systemic:*' node system
systemic:index Adding component routes.admin to system routes +0ms
systemic:index Adding component routes.api to system auth +2ms
systemic:index Adding component routes to system auth +1ms
systemic:index Including definitions from sub system routes into system server +0ms
systemic:index Starting system server +0ms
systemic:index Inspecting component routes.admin +0ms
systemic:index Starting component routes.admin +0ms
systemic:index Component routes.admin started +15ms
systemic:index Inspecting component routes.api +0ms
systemic:index Starting component routes.api +0ms
systemic:index Component routes.api started +15ms
systemic:index Inspecting component routes +0ms
systemic:index Injecting dependency routes.admin as routes.admin into routes +0ms
systemic:index Injecting dependency routes.api as routes.api into routes +0ms
systemic:index Starting component routes +0ms
systemic:index Component routes started +15ms
systemic:index Injecting dependency routes as routes into server +1ms
systemic:index System server started +15ms