I love Node.js. I’ve re-discovered Javascript through it, and I’m never going back. I also love Express. It makes writing server applications so simple, and its Connect-based middleware stack approach makes extending and composing applications easy and fun. Node.js, combined with frameworks like Express, is great for microservices. Thanks to its lightweight character, non-blocking nature, and quick development experience, it beats (imho) other microservice technologies such as Spring Boot. Couple it with Docker and the sky’s the limit (…as long as you allocate enough resources to your container cluster, that is).

Smaller than small

First they gave us Servers, so we built Service-Oriented Architectures.

Then they gave us Containers, so we built Microservices.

Now they give us Event Handlers, so we’ll build Cloud Functions.

As we made our hosting platforms more amenable to deploying smaller units, so have our applications broken down into smaller software packages. There are many reasons for this, and there are diverging opinions on whether it’s a good thing. But if we look back at the original concepts behind cloud computing, there was a dream of having code distributed infinitely in a network of connected computation nodes. And we’re getting a little closer with the emergence of serverless platforms.

But not too small

We cannot go too small because we have blocks (procedures) that consist of sequences of computational steps that require shared memory in order to execute effieciently. Then we wrap those around a function definition, that defines a contract for its input and output, which allows it to be composed with other such functions.

This approach has been very successful in the architecture of Unix, and is one of the reasons for its longevity and ubiquity. I don’t mean to suggest that Web applications should follow a comparable cloud-based shared eco-system (although some are trying), but I do believe that we could benefit from applying similar principles when building Web applications.