MoleculerJS Is Your NodeJS Framework For Microservices

GithubMongoDBPostgreSQLAmazonageing architectureDevOpsMicroserviceMoleculerJSRedisSpotifyNodeJS

MoleculerJS is a fast, modern and powerful microservices framework for Node.js. It helps you to build efficient, reliable & scalable services for your web and mobile apps. MoleculerJS provides many features for building and managing your microservices. These include supporting event-driven architecture with balancing, middlewares and versioned services. You can find the full explanation of their features in the Moleculer’s documentation. But before we dive completely into the wonders of MoleculerJS, let’s first gain an overview of what microservices are all about.


What are microservices?

A microservice architecture, or simply microservices, is a distinctive method for developing software systems that builds single-function modules with well-defined interfaces and operations. The architectural style structures an application as a collection of services that are:


    • Highly maintainable and testable
    • Loosely coupled
    • Independently deployable
    • Organized around business capabilities.


The microservice architecture enables continuous delivery and deployment of large, complex applications. It also enables an organization to evolve its technology stack. With those attractive features, microservices have grown popular in recent years as everything from startups to enterprises looking to become more agile and move towards DevOps approach with continuous testing.


Thanks to its scalability, this microservice architectural method is considered particularly ideal when you have to enable support for a wide range of platforms and devices, for example, web, mobile, Internet of Things, dapps, etc. or simply when you’re not sure what kind of devices you’ll need to support in an uncertain future.


The whole idea behind microservices architecture is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. In other words, each component is developed separately, and the application is then simply the sum of its individual components. In a microservices architecture, each service runs a unique process and usually manages its own database. This not only provides development teams with a more decentralized approach to building software, it also allows each service to be deployed, rebuilt, redeployed and managed independently.


Compartmentalisation at its best, doing its best


The philosophy of the microservices architecture is to “Do one thing and do it well”. Services might run within the same process, but they can be independently deployable and replaced easily. Additionally, they can be implemented using different programming languages, databases, and software environments. The services are small, fine-grained to perform a single function. Microservices embrace automation of testing and deployment, continuous software development processes, failure and faults, similar to anti-fragile systems. Each service is elastic, resilient, composable, minimal, and complete.

If you have heard of microservices you have probably also heard about containers and Docker. Containers are designed to be pared down to the minimal viable pieces needed to run whatever the one thing the container is designed to do. This is rather than packing multiple functions into the same machine. The ease of development that Docker provides help make possible rapid development and testing, similar to microservices.


Using containers and microservices together enhances cloud capabilities. Microservices is scalable and reusable, while containers supply efficient resources. Both microservices and containers can work independently, but it has become clear that merging them has improved runtime frequency, cloud-hosting policies and cloud tools.


Who is using microservices?


An extensive list of mainstream online services that just keeps growing is using microservices. Based on our research, Netflix, eBay, Walmart, Spotify, Amazon, the UK Government Digital Service, Twitter, PayPal and The Guardian are just a few of the many large-scale websites and applications that have all evolved from monolithic to microservices architecture. Let’s look at some of the success stories to see the result.


Walmart Canada

Wallmart Canada

This is an awesome example of what should be done when ageing architecture begins to affect large-scale business negatively. When it comes to enterprise, moving from a monolith system to a microservice architecture is often not a multi-million dollar question for the IT Department. This is the obstacle Walmart Canada had to address after they were failing on Black Fridays for two years in a row.

The problem that Walmart Canada faced was that their webshop couldn’t handle 6 million pageviews per minute during Black Friday and this made it impossible to maintain any kind of positive user experience. Before embracing microservices, Walmart had an architecture for the internet in 2005, designed around desktops and laptops.

Rebuilding Wallmart.ca


The company decided to rebuild its old legacy system in 2012 since it was unable to scale for 6 million page views per minute. Their website broke down for most of the day during peak events like Black Friday. The shift away from the old legacy system was to prepare for the world by 2020. So Walmart re-platformed to a microservices architecture with the intention of achieving close to 100% availability at reasonable costs. Migrating to microservices actually brought notable results:


  • Conversions were up by 20% literally overnight
  • Mobile orders were up by 98% instantly
  • No downtime on Black Friday or Boxing Day
  • The operational savings were significant as well since the company moved off of its expensive hardware onto commodity hardware
  • They saved 40% of the computing power and experienced 20-50% cost savings overall





Kevin Goldsmith, VP of Engineering at Spotify, knows better than any that an enterprise which intends to move fast and stay innovative in a highly competitive market requires an architecture that can scale.

Spotify recently surpassed the 100 million active users per month mark, with an average session length of 23 minutes. All this while running incredibly complex business roles behind the scenes. So, Spotify came to the conclusion instead of worrying about scaling to hundreds of millions of users, they needed to build their system in a way that they could scale components independently. Spotify built a microservice architecture with autonomous full-stack teams in charge in order to avoid synchronization hell within the organization. These teams are autonomous, and their mission does not overlap with other teams mission.


Spotify use of microservices today


Now, Spotify has more than 90 teams, 600 developers, and 5 development offices on 2 continents building the same outstanding product, so they needed to minimize these dependencies as much as possible.

Perhaps the largest benefit that Spotify reaps from using microservices is that they don’t have large failures; big services fail big, small services fail small. Building a microservices architecture allows Spotify to have a large number of services down at the same time without the users even noticing it. They’ve built their system assuming that services can fail all the time. Individual services that could be failing are not doing too much, so they can’t ruin users experience of using Spotify.

Amazon has also migrated to microservices. They get countless calls from a variety of applications, including applications that manage the web service API as well as the website itself. This would have been simply impossible for their old, two-tiered architecture to handle.


In 2001, the Amazon.com was a large architectural monolith. It was architected into multiple tiers. Those tiers had many components,but coupled together in a spiderweb. As a result they behaved like one big clunky monolith. They had a large number of developers working on one big monolithic webshop. Though each one of these developers only worked on a very small piece of that application, they still needed to deal with the overhead of coordinating their changes with everyone else who was also working on the same project.


A bumpy start


Things are not simple if someone on the team wants to add a new feature or making a bugfix. They needed to make sure that the change is not going to break something else on that project. If they wanted to update a shared library to take advantage of a new feature, they needed to convince everyone else on that project to upgrade to the new shared library at the same time. If they needed to make a quick fix, push out to their customers quickly, they couldn’t just do it on their own schedule. They had to coordinate that with all the other developers who have been processing changes at the same time.


Quick fixes never last


In the early 2000’s Amazon even had an engineering group whose sole job was to take new versions of the application and manually push it across Amazon’s production environment.

In short, a very long, cumbersome and complex process. True developer hell. It was frustrating for software engineers. Most importantly, it was slowing down the software development lifecycle and the ability to innovate. As a result, the Amazon team made architectural and organizational changes.


How did Amazon change?


Changes began on an architectural level. Amazon went through its monolithic application into a Service Oriented Architecture. Amazon also implemented changes in how their organization operated. They broke down their one, central, hierarchical product development team into small, “two-pizza teams”. This quote from Jeff Bezos later became famous. They wanted teams so small that they could feed them with just two pizzas. In reality, it’s 6-8 developers per team. Each of these teams got full ownership of one or a few microservices. So they were defining their own feature roadmap, designing their features, implementing their features, then test them, deploy them and operate them.

Amazon dramatically improved its front-end development lifecycle once these changes were made. Now the product teams can quickly make decisions and crank out new features for their microservices. Now the company makes 50 million deployments a year, thanks to the microservice architecture and their continuous delivery processes.


How is Moleculer unique?


Now that we have established the many benefits and use cases for microservices, let’s dive into why Molecular is unique and incredibly useful to anyone building on a microservices architecture.

Building JavaScript web and mobile applications using NodeJS have always had multiple advantages. One is that you can write both frontend and backend code in the same programming language, which ultimately results in high performance. For Moleculer, speed is at the epicenter of it’s value proposition to developers building microservices.




To sum up, MoleculerJS is one of the best microservices out there. By looking at companies like Amazon, Wallmart Canada and Spotify we have seen how microservices can turn the websites of your organisations around by making things run more efficiently. They are are the backbone for a well-oiled website, app or platform.


Whatever project you have immersed yourself in, if you are building in NodeJS you ought to think about using Moleculer as a microservice framework to deploy and service your applications. For the official Github and site. Alternatively, you can contact Wiredelta to help you with using this amazing microservices or any other web or app projects you have in mind.


Follow us here and on social media to keep up to date with the latest developments in all things tech.

Leave a Reply

Your email address will not be published. Required fields are marked *