Microservices are a very old idea that have picked up a new head of steam, and they are becoming a very popular approach to building applications with node.js.

I have written about them in the past, but I have many months of experience migrating a monolithic app to a set of services now, so it was a good time to bundle everything up and share the knowledge.

Slides from this presentation: arrow keys or space navigates between slides.

Instead of building a single application, why not build many applications that communicate over standard network protocols? With each service being very small (often around 100 lines of code), they become very easy to build and compose into new systems.

While they do have a lot of promise of being much more developer friendly, flexible and scaleable, there is no such thing as a silver bullet, and every benefit comes with some drawbacks.

Originally built for the Node.js Cape Town user group, but I have presented these a couple of times since. The microservice slides, and source code are available on my github account.

Last week we had the introduction to my series on the Full-Stack Fundamentals, but I left some in my target audience confused as to why they needed to be pay attention. This is completely understandable because, for an industry that requires precision, we use a lot of terminology that is actually quite ill-defined.

After some research I’ve concluded that being a “Full-Stack Engineer” has a range of meanings, and it’s probably best if I show you the bigger picture.

Recently, I’ve been mentoring a few full-stack developers through a process that bears some similarity to the Meerkat Method. Since I also intend to publish a series of articles about the whole journey, I have to be careful to keep things factual and honest.

This puts me in a quandary, because my recent stint on the job market has shown that just about everybody is using MongoDB, and I’ve just never been in any situation that I have needed to use it.

I also can’t foresee any situation where there is a solid technical reason for choosing MongoDB over it’s competitors either, and the last thing I want to do is lead people astray or foist my preconceptions onto them.

This is the first in a series documenting the process of building out an example application for the Seneca.js framework, which is built around the concept of microservices. This post is more about the theory behind microservices though, to lay the groundwork for future posts as I embark on this journey.

NearForm is paying for the development work, but blogging about it is all me.

This post has nothing to do with any technical similarity between the two systems.

It is the conclusion of a series of posts, in which I have attempted to understand why my instincts were telling me to avoid Angular.js at all costs.

This is the second in a series of notes I have made about an enlightening presentation called Simple Made Easy by Rich Hickey, the creator of Clojure.

Recently I was directed to an enlightening presentation called Simple Made Easy by Rich Hickey, the creator of Clojure.

Because it’s really difficult to justify asking someone to watch an hour long presentation just to be able to use the same terminology, I’m publishing some notes here in a more easily digestible format. This is not a direct transcription, but more of a selective overview of the parts I consider the most important.

I still highly recommend that you watch at least the first half of the presentation itself. While it does become a tad Clojure-specific at times, on the whole it remains broadly relevant. There are also slides from the presentation up on slideshare, from which I have taken some screencaps for this post.

In recent weeks I have been trying to resolve why I had such a visceral reaction to Angular.js, that I even started dreaming about it.

After having worked my way through the parts of Angular.js that concerned me the most, I think that I have finally narrowed it down to the fact that I believe the way it tries to infer dependencies is a critical mistake.