Hi

I returned late Sunday night from a trip to the south of France, where I was privileged to speak about Microservices, OpenShift, and how to do it all on Node.js. The conference was RivieraDev/JUDCon: Riviera 2017 and took place in Sophia Antipolis, near Nice, Cannes, St. Tropez and other fabulous Mediterranean cities on the southeastern coast of France.

One of the predominant patterns in today's Node.js applications is the microservice, or µ-service. Applications are composed of a suite of independently deployable services, usually running in independent processes. These µ-services typically communicate with each other using lightweight protocols such as REST over HTTP.

One of the side effects of this architecture, however, is that applications need to be designed to handle failure. Any one of the service calls could fail for any number of reasons at any time. Today, I'll explore one method you can employ to gracefully handle service unavailability — the Circuit Breaker pattern.

A couple of weeks ago, I wrote a fairly long post attempting to shed some light on a few things you can do in your JavaScript classes to enforce the concept of data encapsulation - or data "hiding". But as soon as I posted it, I got some flak from a friend who is a Clojure programmer. His first comment about the article was this.

Mutability and data encapsulation are fundamentally at odds.

Eventually, he walked that back - but only just a little bit. His point, though, was intriguing. I asked him to explain what he meant.

For a lot of my early career, I was an OO developer. I genuflected regularly in front of the altar of data encapsulation, object heirarchies and static typing. And the syntax. Oh the syntax!

But I have changed, of course, and so much of the dogma and ceremony that I participated in during those times has come to seem a lot less important than it was 20 years ago. Languages, and developers evolve. But that doesn't mean there aren't some really good lessons to learn.

Take, for instance, data encapsulation.