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

seneca-legacy

v1.0.1

Published

A Micro-Services Framework for Node.js (legacy - do not use)

Downloads

3

Readme

seneca - Node.js module

A Node.js toolkit for startups building Minimum Viable Products

Seneca is a toolkit for organizing the business logic of your app. You can break down your app into "stuff that happens", rather than focusing on data models or managing dependencies.

For a gentle introduction to this module, see the senecajs.org site.

If you're using this module, feel free to contact me on twitter if you have any questions! :) @rjrodger

Current Version: 0.5.14

Tested on: Node 0.10.19, and 0.11, 0.8 on Travis

Build Status

Use this module to define commands that work by taking in some JSON, and, optionally, returning some JSON. The command to run is selected by pattern-matching on the the input JSON. There are built-in and optional sets of commands that help you build Minimum Viable Products: data storage, user management, distributed logic, caching, logging, etc. And you can define your own product by breaking it into a set of commands - "stuff that happens".

That's pretty much it.

Why do this?

It doesn't matter,

  • who provides the functionality,
  • where it lives (on the network),
  • what it depends on,
  • it's easy to define blocks of functionality (plugins!).

So long as some command can handle a given JSON document, you're good.

Here's an example:

var seneca = require('seneca')()

seneca.add( {cmd:'sales-tax'}, function(args,callback){
  var rate  = 0.23
  var total = args.net * (1+rate)
  callback(null,{total:total})
})

seneca.act( {cmd:'salestax', net:100}, function(err,result){
  console.log( result.total )
})

In this code, whenever seneca sees the pattern {cmd:'sales-tax'}, it executes the function associated with this pattern, which calculates sales tax. Yah!

The seneca.add method adds a new pattern, and the function to execute whenever that pattern occurs.

The seneca.act method accepts an object, and runs the command, if any, that matches.

Where does the sales tax rate come from? Let's try it again:

seneca.add( {cmd:'config'}, function(args,callback){
  var config = {
    rate: 0.23
  }
  var value = config[args.prop]
  callback(null,{value:value})
})

seneca.add( {cmd:'salestax'}, function(args,callback){
  seneca.act( {cmd:'config', prop:'rate'}, function(err,result){
    var rate  = parseFloat(result.value)
    var total = args.net * (1+rate)
    callback(null,{total:total})
  })
})

seneca.act( {cmd:'salestax', net:100}, function(err,result){
  console.log( result.total )
})

The config command provides you with your configuration. This is cool because it doesn't matter where it gets the configuration from - hard-coded, file system, database, network service, whatever. Did you have to define an abstraction API to make this work? Nope.

There's a little but too much verbosity here, don't you think? Let's fix that:

var shop = seneca.pin({cmd:'*'})

shop.salestax({net:100}, function(err,result){
  console.log( result.total )
})

By pinning a pattern, you get a little API of matching function calls. The shop object gets a set of methods that match the pattern: shop.salestax and shop.config.

Programmer Anarchy

The way to build Node.js systems, is to build lots of little processes. Here's a great talk explaining why you should do this: Programmer Anarchy.

Seneca makes this really easy. Let's put configuration out on the network into it's own process:

seneca.add( {cmd:'config'}, function(args,callback){
  var config = {
    rate: 0.23
  }
  var value = config[args.prop]
  callback(null,{value:value})
})


seneca.use('transport')

var connect = require('connect')
var app = connect()
  .use( connect.json() )
  .use( seneca.export('web') )
  .listen(10171)

The transport plugin exposes any commands over a HTTP end point. You can then use the connect module, for example, to run a little web server. The seneca.export('web') function call returns a connect middleware function to do this.

Your implementation of the configuration code stays the same.

The client code looks like this:

seneca.use('transport',{
  pins:[ {cmd:'config'} ]
})

seneca.add( {cmd:'salestax'}, function(args,callback){
  seneca.act( {cmd:'config', prop:'rate'}, function(err,result){
    var rate  = parseFloat(result.value)
    var total = args.net * (1+rate)
    callback(null,{total:total})
  })
})

var shop = seneca.pin({cmd:'*'})

shop.salestax({net:100}, function(err,result){
  console.log( result.total )
})

On the client-side, the transport plugin takes a pins parameter. You can use this to specify which patterns are remote.

Again, notice that your sales tax code does not change. It does not need to know where the configuration comes from, who provides it, or how.

You can do this with every command.

Keeping the Business Happy

The thing about business requirements is that have no respect for common sense, logic or orderly structure. The real world is messy.

In our example, let's say some countries have single sales tax rate, and others have a variable rate, which depends either on locality, or product category.

Here's the code. We'll rip out the configuration code for this example.

// fixed rate
seneca.add( {cmd:'salestax'}, function(args,callback){
  var rate  = 0.23
  var total = args.net * (1+rate)
  callback(null,{total:total})
})


// local rates
seneca.add( {cmd:'salestax',country:'US'}, function(args,callback){
  var state = {
    'NY': 0.04,
    'CA': 0.0625
    // ...
  }
  var rate = state[args.state]
  var total = args.net * (1+rate)
  callback(null,{total:total})
})


// categories
seneca.add( {cmd:'salestax',country:'IE'}, function(args,callback){
  var category = {
    'top': 0.23,
    'reduced': 0.135
    // ...
  }
  var rate = category[args.category]
  var total = args.net * (1+rate)
  callback(null,{total:total})
})


var shop = seneca.pin({cmd:'*'})

shop.salestax({net:100,country:'DE'}, function(err,result){
  console.log( 'DE: '+result.total )
})

shop.salestax({net:100,country:'US',state:'NY'}, function(err,result){
  console.log( 'US,NY: '+result.total )
})

shop.salestax({net:100,country:'IE',category:'reduced'}, function(err,result){
  console.log( 'IE: '+result.total )
})

In this case, you provide different implementations for different patterns. This lets you isolate complexity into well-defined places. It also means you can deal with special cases very easily.

Design Notes

Specific Minor Decisions

  • Modules in package.json should have exact versions. Seneca is infrastructure, so needs to be conservative and only use verified versions.

Acknowledgements

This module depends on many, many Node.js modules - thank you!

Development is sponsored by nearForm