// the find
senecajs/seneca
A microservices toolkit for Node.js.
Seneca is a pattern-matching message bus for Node.js microservices. You register handlers keyed by JSON property patterns, and Seneca routes incoming messages to the right handler whether it's in-process or across the network. It's for teams who want to decompose business logic into small, independently deployable services without agreeing on a transport protocol upfront.
Pattern-matching dispatch is genuinely clever — adding a handler for `{cmd:'salestax', country:'US'}` automatically overrides the generic handler without touching existing code, which makes incremental specialization clean. The `prior()` mechanism for middleware chaining is well-designed and lets you extend existing handlers without monkey-patching. Transport abstraction actually works: switching from in-process to HTTP or a message bus requires no changes to handler code. Test coverage is serious — the test directory has files for nearly every subsystem and the test infra looks mature.
This is essentially a 2014 architecture. The callback-based API (`done(null, result)`) hasn't fully transitioned to Promises/async-await despite the README's 2018 copyright — the quick example still uses callbacks throughout, which is a red flag for any modern Node.js codebase. The ecosystem of plugins it touts is largely abandoned; most seneca-* packages on npm haven't been updated in years, so 'built-in' features like user management and caching are phantom dependencies. There's no built-in schema validation on messages, so pattern dispatch silently swallows malformed input. At under 4k stars after 15+ years, the community has clearly moved on to gRPC, NATS, or just HTTP — adopting this today means betting on a maintenance-mode project.