Context

I recently built a Minimum Viable Product for a client using microservices.  Before launching into building a microservices framework of my own I thought it would be worth taking a few minutes to check out whether someone else had done it for me, made all the mistakes I was likely to make and corrected them.  Given that I was developing in Node.js it didn’t take long to find Seneca.

Introducing Seneca

After reading about the genesis of Seneca and following the excellent quick start tutorial I decided that it was worth giving Seneca a try. Richard Rodger, the founder of nearForm and principal author of Seneca has written a great article explaining how it came about.  It wasn’t developed as a microservices framework at all, but was rather a means of efficiently building Minimum Viable Products. The ideal way to build an MVP is to quickly plug together building blocks of functionality (e.g. user accounts, database connectors, shopping carts, etc.) so as to end up with an application that works without any further input.  You can then enhance this basic framework to create your special product.

Rodger liked what Ruby on Rails and Django for Python were trying to achieve, but neither system provided the kind of unifying structure he was looking for. Having used Ruby on Rails myself I know what he means. As an alternative he took inspiration from UNIX command line tools which can be piped together using streams of data. Taking this a step further, he adopted the kind of pattern matching used to facilitate ‘black box’ components in functional programming.  Having investigated Erlang myself recently for a project idea of my own I was even more drawn to Seneca.

A tried and tested approach

Functional programming is a style of coding where you build small blocks of code that do one thing (or ‘function’) only.  Functional components are defined by the messages they accept and the messages they emit.  Each component neither knows nor cares about any other component, they simply listen for messages to which they respond, act on these messages and emit an output.  If no other component responds to their output then so be it! Like any other software solution, Seneca is not a silver bullet.  It is not a set of ‘lego bricks’ which can be made into an airplane or a robot by following a set of instructions.  You need to understand how it fits together to use it properly.  Neither is it a library of utilities.  It has quite a large number of available components and you need to look carefully at how these plugins work to understand what they do and how to use them.  Once you have understood its architecture and mastered a couple of plugins it makes a great deal of sense and becomes a fast way of assembling just the kind of structure I was looking for in developing an MVP.

Seneca-neo4j-store

So much so, in fact, that I have contributed a plugin myself.  I want to use Neo4j as the persistence mechanism for my MVP and although Seneca already had a Neo4j store plugin it was quite out of date so I made one of my own and contributed it to Seneca.  When I told Seneca I had created this plugin they were nice enough to let me take over their existing npm module so I added my code on top of their own and a new plugin was born (well, an old plugin was given a new lease of life).

Where next?

In my next blog post I’ll explain how to use my Neo4j plugin by extending the Seneca user plugin.  I’m also in the process of creating a 4-node Raspberry Pi tower to explore containerisation, microservices and Seneca in a distributed computing environment that I can easily control.  Watch this space to find out how I get on.