a Microservice Microframework for Node; node-xyz (part 1)

In this article I want to tell you the story of how I decided to write a microservice framework for node. I will also go into some of the details of the implementation.

This writing is consisted of two part:

1. The story of xyz (this page)
2. The technical aspects

First, let’s talk about how I ended up here.

Microservice development; How I saw it

more than two years ago, I first heard of the term “microservice”. It was quite vague for me at the time. As time went by and I read more and more about it, I started to get it. It made sense like “two times two makes a four” makes sense. natural and intuitive.

I had the chance to actually implement this idea for a few projects and that’s when I felt that something about the development trends (at the time) didn’t match with the way that I like to do things.

From my perspective, I saw two main approaches:

1. Build from scratch to build something simple.
2. Rely heavily on 3rd party libraries to build a beast.

The first approach is fine. Perhaps not always practical for business but it’s fine. The second one on the other hand, not so much.

See, I’m the type of guy who likes to be in control. I don’t like magical frameworks that do all of the work in the background. I don’t like $ magic-lib create-ms customer-service, $ magic-lib set-up message-queue, $ magic-lib deploy customer-service. Don’t get me wrong. I’m not saying that these types of tools should not exist. We have all used them , specially near our deadlines, and and prayed for their authors. Many big projects also use them very frequently. Nonetheless, I think it’s also valuable when you start building an app where you have complete power over it, when you know every bit of it. Not when something else has power over your app (no wonder why I never liked Meteor!).

How I feel when I’m using too way too many libraries

Furthermore, I am not a fan of relying too much on 3rd party libraries. I personally believe that sometimes they can be an impediment than a help. Specifically when you want to start small and improve incrementally, dealing with the headache of developing something simple and correct from scratch is better than dealing with hundreds of config files and dependency managements and getting it wrong at the end anyway (not liking 3rd party tools turned out to be very hard nowadays if you are a Javascript developer).

This led me to wish for a toolkit/framework that is comprehensive and thorough, yet lucid enough to don’t give that feeling of loosing control over what is happening.

Node, Oh Lovely Node

And then there was Node. My favorite language/platform in the world. It’s more than personal affinity when it comes to microservices and Node. They add up pretty good. Node suggests a lightweight runtime best suited to run independent modules which fit into a microservice based system pretty neatly. A node process is technically bound (or should I say, doomed) to don’t do more than a certain amount of computation. On the other hand it can do that limited amount of process reliably. Exactly what we need for microservices.

node-xyz; microservice microframework

The combination of these two feelings led to this phrase, explaining what I longed for, “a Microservice Microframework for node”.

I decided to name it node-xyz. node, well, because it’s for Node, and xyz because of the scalability cube.

I placed these objectives in mind and started working on it as a spare time project:

• Support the portion of the microservice spec. that is required for almost all projects. Messaging, Service Discovery etc.
• Stay minimal.
• Be as clear and lucid as possible. Not another “you don’t need to know what’s happening” framework.
• Be as configurable as possible. It is true that as a framework it should take control over the developer’s code, but at least let the developer decide how it takes over it. (this is why I chose “micro-framework” instead of “framework”)

The difference between a framework and a library, by definition, is that a library is used by your code, while a framework will use your code.

• Use standard javascript. Have minimum dependencies.
• Document early and often

Now

This was what was in my mind almost a year ago. And now, one year later, xyz is partially developed. In the next part of this writing I will describe what the outcome of it has turned out to be.