Seneca
By the Seneca open-source community
js that organizes application logic around pattern-matched messages rather than fixed function calls or HTTP routes. Services register actions that respond to specific message patterns, and Seneca handles routing a message to the right…
Definition
Seneca is a toolkit for building microservices in Node.js that organizes application logic around pattern-matched messages rather than fixed function calls or HTTP routes. Services register actions that respond to specific message patterns, and Seneca handles routing a message to the right action locally or across a network, letting the same code run as a monolith during development and be split into distributed services later without rewriting business logic.
Overview
Seneca was built around the idea that microservice boundaries should be a deployment decision, not a design-time decision baked into how code is written. In many microservice frameworks, splitting a service into two means rewriting internal function calls as HTTP or message-queue calls; Seneca tries to avoid that rewrite by having all interactions, whether they end up local or remote, expressed the same way from the start: as pattern-matched messages. Mechanically, a Seneca application defines actions using `.add()`, associating a pattern object, such as `{role: 'math', cmd: 'sum'}`, with a handler function, and triggers behavior using `.act()` with a matching pattern. Seneca's pattern matcher finds the best-matching registered action for a given message, similar in spirit to how Reach Router ranks route matches, and the underlying transport, in-process function calls, HTTP, or a message queue, is a configuration detail rather than something the calling code needs to know about. This lets a team run an entire system as a single process during development and later move specific actions to separate deployed services purely through configuration changes. Seneca's message-pattern model differs from more conventional microservice approaches built on explicit REST or gRPC service contracts, and from lighter Node.js microservice toolkits that assume a fixed transport from the start. Its closest conceptual relatives are other pattern-based or actor-style messaging systems rather than typical HTTP frameworks like Express or Fastify, which Seneca can actually run on top of for its HTTP transport. In practice, Seneca has been used to build systems that need to evolve gradually from a monolith into microservices, letting teams defer the operational complexity of a fully distributed system until it is actually needed, while still writing code in the eventual microservice style. It has also been used in plugin-heavy systems where third-party or team-specific plugins add new message patterns to a shared application. The main trade-offs are that Seneca's pattern-matching abstraction adds a layer of indirection that can make tracing which code handles a given message less immediately obvious than a direct function call or an explicit REST route, and its adoption and active development have slowed relative to newer microservice tooling, so teams evaluating it today should weigh its smaller, less active community and ecosystem against its distinctive gradual-microservices approach. Newer microservice frameworks with more conventional service-contract models and larger communities, such as Moleculer or NestJS's own microservice transport layer, have absorbed much of the attention Seneca once received, which is a further factor for teams comparing long-term support options.
Key Features
- Actions are registered against message patterns rather than fixed routes
- Same code can run as a monolith or be split into distributed services
- Transport for messages, local calls, HTTP, or queues, is a configuration detail
- Pattern matcher selects the best-matching action for a given message
- Plugin system allows extending an application with new message patterns
- Supports gradual evolution from monolithic to microservice architecture