Evolution of Seneca
It’s been a long road for Seneca. It started life back in 2010 as a one-man project by nearForm CTO, Richard Rodger – “one developer’s itch”, as he describes it. It quickly gained a small but dedicated following and began to grow and evolve. Today, it is a fully functional microservices toolkit for Node.js that is in production use in several organizations worldwide, including Intel and CoderDojo. It is also the core of a vibrant open source community and a growing team of contributors.
Improvements in Seneca 1.0
This release of Seneca represents the culmination of a long period of ecosystem-wide work to provide stability and ease of use across the board. We wanted to focus our efforts on creating a solid foundation for our community and users to work with.
With this in mind, I wanted to share some of the high-level changes and improvements we have made across the organization:
- Quality and maintenance
- Business logic components (plugins)
- Major cleanup across the board on all plugins
- Deprecated various projects in favour of community-created ones
- Data entities
- Major cleanup efforts across the board on all stores
- Documentation improvements
- Initial ground work to move Entities into its own plugin
- Service discovery
- Third party integration
- Implemented Charka CoC across the organization
- Appointed lead maintainers to key projects
Core principles of Seneca
The ethos of the Seneca framework is to place the needs of developers above the needs of maintainers. In line with this ethos, the core principles of Seneca are as follows:
- Acceptance. All uses of Seneca are valid and accepted. To make this possible, the core API is kept small, and there is a plugin and decoration mechanism so that developers can make Seneca their own.
- Brevity. To quote a recent blog post by Matteo Collina, architect at nearForm and core contributor to Seneca, “no code is better than any code”. In other words, less is more. Seneca enables you to write clean, concise code so that you have less to think about and write fewer bugs. To do this, it provides a chainable API, an abbreviated form of JSON, and an abbreviated way to load plugins.
- Continuity. Seneca won’t break your code. Major releases with API changes provide a plugin to support the previous release, so that you can continue to use your old code with a one-line addition.
Just because a project is open source shouldn’t mean that its developers have to put up with poor documentation.
Even when it was still little more than a twinkle in its creator’s eye, Seneca placed a high value on good quality documentation. The new version features enhanced tutorials, comprehensive API and plugin docs, and a super-detailed getting started guide.
As part of nearForm’s stewardship, our in-house writer and editor regularly quality checks the Seneca docs and makes corrections and improvements to maintain standards.
Seneca exists today because of the commitment, enthusiasm and hard work of several contributors in the areas of coding, quality assurance, writing, editing and testing. See the full list of contributors’ names.
Find out more
See Richard Rodger’s own blog post for a detailed account of the genesis of Seneca right up to the new release.