Installations
npm install seneca
Developer Guide
Typescript
Yes
Module System
CommonJS
Min. Node Version
>=14
Node Version
20.11.1
NPM Version
10.2.4
Score
84.8
Supply Chain
99.2
Quality
82.2
Maintenance
100
Vulnerability
98.9
License
Releases
Contributors
Unable to fetch Contributors
Languages
JavaScript (65.07%)
TypeScript (34.74%)
Shell (0.19%)
Developer
Download Statistics
Total Downloads
4,263,296
Last Day
840
Last Week
6,439
Last Month
33,893
Last Year
524,305
GitHub Statistics
3,964 Stars
1,858 Commits
311 Forks
136 Watching
15 Branches
60 Contributors
Package Meta Information
Latest Version
4.0.0-rc4
Package Id
seneca@4.0.0-rc4
Unpacked Size
629.58 kB
Size
149.91 kB
File Count
80
NPM Version
10.2.4
Node Version
20.11.1
Publised On
12 Jul 2024
Total Downloads
Cumulative downloads
Total Downloads
4,263,296
Last day
-44.4%
840
Compared to previous day
Last week
-12.8%
6,439
Compared to previous week
Last month
5.4%
33,893
Compared to previous month
Last year
-22.5%
524,305
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Dependencies
14
A Node.js toolkit for Microservice architectures
This open source module is sponsored and supported by Voxgig. |
---|
Seneca
- Lead Maintainer: Richard Rodger
- Sponsor: voxgig
Seneca is a toolkit for writing microservices and 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.
Seneca provides,
-
pattern matching: a wonderfully flexible way to handle business requirements
-
transport independence: how messages get to the right server is not something you should have to worry about
-
maturity: 8 years in production (before we called it microservices), but was once taken out by lightning
-
plus: a deep and wide ecosystem of plugins
-
book: a guide to designing microservice architectures: taomicro
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.
If you're using this module, and need help, you can:
- Post a github issue,
- Tweet to @senecajs,
- Ask on the Gitter.
If you are new to Seneca in general, please take a look at senecajs.org. We have everything from tutorials to sample apps to help get you up and running quickly.
Seneca's source can be read in an annotated fashion by running npm run annotate
. An
annotated version of each file will be generated in ./docs/
.
Install
To install via npm,
npm install seneca
Quick Example
1'use strict' 2 3var Seneca = require('seneca') 4 5 6// Functionality in seneca is composed into simple 7// plugins that can be loaded into seneca instances. 8 9 10function rejector () { 11 this.add('cmd:run', (msg, done) => { 12 return done(null, {tag: 'rejector'}) 13 }) 14} 15 16function approver () { 17 this.add('cmd:run', (msg, done) => { 18 return done(null, {tag: 'approver'}) 19 }) 20} 21 22function local () { 23 this.add('cmd:run', function (msg, done) { 24 this.prior(msg, (err, reply) => { 25 return done(null, {tag: reply ? reply.tag : 'local'}) 26 }) 27 }) 28} 29 30 31// Services can listen for messages using a variety of 32// transports. In process and http are included by default. 33 34 35Seneca() 36 .use(approver) 37 .listen({type: 'http', port: '8260', pin: 'cmd:*'}) 38 39Seneca() 40 .use(rejector) 41 .listen(8270) 42 43 44// Load order is important, messages can be routed 45// to other services or handled locally. Pins are 46// basically filters over messages 47 48 49function handler (err, reply) { 50 console.log(err, reply) 51} 52 53Seneca() 54 .use(local) 55 .act('cmd:run', handler) 56 57Seneca() 58 .client({port: 8270, pin: 'cmd:run'}) 59 .client({port: 8260, pin: 'cmd:run'}) 60 .use(local) 61 .act('cmd:run', handler) 62 63Seneca() 64 .client({port: 8260, pin: 'cmd:run'}) 65 .client({port: 8270, pin: 'cmd:run'}) 66 .use(local) 67 .act('cmd:run', handler) 68 69 70// Output 71// null { tag: 'local' } 72// null { tag: 'approver' } 73// null { tag: 'rejector' }
Running
To run normally, say in a container, use
1$ node microservice.js
(where microservice.js
is a script file that uses Seneca).
Logs are output in JSON format so you can send them to a logging service.
To run in test mode, with human-readable, full debug logs, use:
$ node microservice.js --seneca.test
Why we built this?
So that 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:
1var seneca = require('seneca')() 2 3seneca.add({cmd: 'salestax'}, function (msg, done) { 4 var rate = 0.23 5 var total = msg.net * (1 + rate) 6 done(null, {total: total}) 7}) 8 9seneca.act({cmd: 'salestax', net: 100}, function (err, result) { 10 console.log(result.total) 11})
In this code, whenever seneca sees the pattern {cmd:'salestax'}
, it executes the
function associated with this pattern, which calculates sales tax. There is nothing
special about the property cmd
. It is simply the property we want to pattern match.
You could look for foo
for all seneca cares! 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:
1seneca.add({cmd: 'config'}, function (msg, done) { 2 var config = {rate: 0.23} 3 var value = config[msg.prop] 4 done(null, {value: value}) 5}) 6 7seneca.add({cmd: 'salestax'}, function (msg, done) { 8 seneca.act({cmd: 'config', prop: 'rate'}, function (err, result) { 9 var rate = parseFloat(result.value) 10 var total = msg.net * (1 + rate) 11 done(null, {total: total}) 12 }) 13}) 14 15seneca.act({cmd: 'salestax', net: 100}, function (err, result) { 16 console.log(result.total) 17})
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:
1seneca.act('cmd:salestax,net:100', function (err, result) { 2 console.log(result.total) 3})
Instead of providing an object, you can provide a string using an abbreviated form of JSON. In fact, you can provide both:
1seneca.act('cmd:salestax', {net: 100}, function (err, result) { 2 console.log(result.total) 3})
This is a very convenient way of combining a pattern and parameter data.
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 its own process:
1seneca.add({cmd: 'config'}, function (msg, done) { 2 var config = {rate: 0.23} 3 var value = config[msg.prop] 4 done(null, { value: value }) 5}) 6 7seneca.listen()
The listen
method starts a web server that listens for JSON
messages. When these arrive, they are submitted to the local Seneca
instance, and executed as actions in the normal way. The result is
then returned to the client as the response to the HTTP
request. Seneca can also listen for actions via a message bus.
Your implementation of the configuration code stays the same.
The client code looks like this:
1seneca.add({cmd: 'salestax'}, function (msg, done) { 2 seneca.act({cmd: 'config', prop: 'rate' }, function (err, result) { 3 var rate = parseFloat(result.value) 4 var total = msg.net * (1 + rate) 5 done(null, { total: total }) 6 }) 7}) 8 9seneca.client() 10 11seneca.act('cmd:salestax,net:100', function (err, result) { 12 console.log(result.total) 13})
On the client-side, calling seneca.client()
means that Seneca will
send any actions it cannot match locally out over the network. In this
case, the configuration server will match the cmd:config
pattern and
return the configuration data.
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 they 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.
1// fixed rate 2seneca.add({cmd: 'salestax'}, function (msg, done) { 3 var rate = 0.23 4 var total = msg.net * (1 + rate) 5 done(null, { total: total }) 6}) 7 8 9// local rates 10seneca.add({cmd: 'salestax', country: 'US'}, function (msg, done) { 11 var state = { 12 'NY': 0.04, 13 'CA': 0.0625 14 // ... 15 } 16 var rate = state[msg.state] 17 var total = msg.net * (1 + rate) 18 done(null, {total: total}) 19}) 20 21 22// categories 23seneca.add({ cmd: 'salestax', country: 'IE' }, function (msg, done) { 24 var category = { 25 'top': 0.23, 26 'reduced': 0.135 27 // ... 28 } 29 var rate = category[msg.category] 30 var total = msg.net * (1 + rate) 31 done(null, { total: total }) 32}) 33 34 35seneca.act('cmd:salestax,net:100,country:DE', function (err, result) { 36 console.log('DE: ' + result.total) 37}) 38 39seneca.act('cmd:salestax,net:100,country:US,state:NY', function (err, result) { 40 console.log('US,NY: ' + result.total) 41}) 42 43seneca.act('cmd:salestax,net:100,country:IE,category:reduced', function (err, result) { 44 console.log('IE: ' + result.total) 45}) 46
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.
Contributing
The Senecajs org encourages participation. If you feel you can help in any way, be it with bug reporting, documentation, examples, extra testing, or new features feel free to create an issue, or better yet, submit a Pull Request. For more information on contribution please see our Contributing guide.
Test
To run tests locally,
npm run test
To obtain a coverage report,
npm run coverage; open docs/coverage.html
License
Copyright (c) 2010-2018 Richard Rodger and other contributors; Licensed under MIT.
Stable Version
Stable Version
4.0.0-rc4
LOW
1
0/10
Summary
Sensitive Data Exposure in seneca
Affected Versions
< 3.9.0
Patched Versions
3.9.0
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
- Info: project has a license file: LICENSE:0
- Info: FSF or OSI recognized license: MIT License: LICENSE:0
Reason
2 existing vulnerabilities detected
Details
- Warn: Project is vulnerable to: GHSA-qwcr-r2fm-qrc7
- Warn: Project is vulnerable to: GHSA-hrpp-h998-j3pp
Reason
dependency not pinned by hash detected -- score normalized to 3
Details
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/build.yml:25: update your workflow using https://app.stepsecurity.io/secureworkflow/senecajs/seneca/build.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/build.yml:27: update your workflow using https://app.stepsecurity.io/secureworkflow/senecajs/seneca/build.yml/master?enable=pin
- Warn: third-party GitHubAction not pinned by hash: .github/workflows/build.yml:35: update your workflow using https://app.stepsecurity.io/secureworkflow/senecajs/seneca/build.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/todo.yml:7: update your workflow using https://app.stepsecurity.io/secureworkflow/senecajs/seneca/todo.yml/master?enable=pin
- Warn: third-party GitHubAction not pinned by hash: .github/workflows/todo.yml:9: update your workflow using https://app.stepsecurity.io/secureworkflow/senecajs/seneca/todo.yml/master?enable=pin
- Warn: npmCommand not pinned by hash: .github/workflows/build.yml:31
- Info: 0 out of 3 GitHub-owned GitHubAction dependencies pinned
- Info: 0 out of 2 third-party GitHubAction dependencies pinned
- Info: 2 out of 3 npmCommand dependencies pinned
Reason
Found 2/30 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
- Warn: no topLevel permission defined: .github/workflows/build.yml:1
- Warn: no topLevel permission defined: .github/workflows/todo.yml:1
- Info: no jobLevel write permissions found
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
- Warn: no security policy file detected
- Warn: no security file to analyze
- Warn: no security file to analyze
- Warn: no security file to analyze
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
branch protection not enabled on development/release branches
Details
- Warn: branch protection not enabled for branch 'master'
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
- Warn: 0 commits out of 2 are checked with a SAST tool
Score
3.4
/10
Last Scanned on 2024-12-16
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More