MEAN stack lets you create real-time websites with push capability and give developers a tool for working in the non-blocking, event-driven I/O paradigm. Node.js shines in real-time web applications by employing push technology over web sockets.
Before MEAN came in, the web was living in a stateless request-response paradigm. MEAN stack brought us real-time web applications with two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely.
This paradigm is quite revolutionary considering traditionally only client used to initiate communication.
As a result, MEAN forms the technology stack of various big enterprises.
MEAN stack certainly shines in building fast, scalable network applications, as it’s capable of handling a huge number of simultaneous connections with high throughput, which equates to high scalability. Unlike traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, MEAN stack development operates on a single-thread, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections held in the event loop.
Suppose we are developing a real-time chat app. It uses traditional web-serving techniques and, consequently, for each new conversation, the program creates a new thread. Let’s say each thread occupies 2MB of RAM and the system has 8GB of RAM installed. The RAM will max out at 4000 concurrent conversations. If you have managed chat support center, then you know 4000 conversations at a time aren’t surprising.
In contrast, a MEAN stack based rea-time chat app can virtually, achieve scalability levels of over 1M concurrent conversation on a single thread in the same amount of RAM. Of course, even the largest of support centers don’t process this many requests at a time.
Companies such as PayPal, Uber, Netflix Walmart, Yahoo, etc. rely on MEAN stack development for a large chunk of their application portfolio. In fact, at PayPal, they rebuilt one of their Java and Spring based applications using Node and it found that the node application was built:
Imagine you go to a restaurant and a waiter comes to your table to take your order and gives it to the kitchen. Then he moves on to serve another table while the chef is preparing your meal and thus can serve many different tables. Diners don’t have to wait for the chef to cook one meal before they serve another table. This is what we call non-blocking or asynchronous architecture.
This is how node applications work: the waiter is like a thread allocated to handle a request. A single thread is used to handle multiple requests.
In contrast to non-blocking or asynchronous architecture, we have blocking or synchronous architecture. Imagine you go to another restaurant, and in this restaurant, a waiter is allocated to you. They take your order and give it to the kitchen now they are sitting in the kitchen waiting for the chef to prepare your meal. At this time, the waiter is not doing anything else. He is not going to take an order from another table until your meal is ready. This is what we call blocking or synchronous architecture and that’s how applications built with frameworks like asp.net or Rails work out of the box.
In Rail, when we receive a request on the server, a thread is allocated to handle that request. As a part of handling that requests, it is likely that we’re going to query a database and sometimes it may take a little while until the result is ready.
When the database is executing the query that thread is sitting there waiting; it can’t be used to serve another client and we need a new thread to serve another client.
In case of real time applications, we have a large number of concurrent clients. At some point, we’re going to runout of threads to serve these clients and new clients have to wait until new threads are available.
With this kind of architecture, we are not utilizing our resources efficiently. This is the problem with blocking or synchronous architecture and that shows applications built with frameworks like asp.net can’t work in real-time due to their blocking nature.
Therefore, MEAN stack development is a natural choice while developing real-time applications due to its non-blocking nature. The application has a single thread to handle all requests when a request arrives, that single thread is used to handle that request.
If we need to query a database, our thread doesn’t have to wait for the database to return the data. While the database is executing our query, that thread will be used to serve another client. When the database prepares the result, it puts a message in what we call an event queue.
Node is continuously monitoring this queue in the background when it finds an event in this queue, it will take it out and process it. This kind of architecture makes MEAN stack ideal for building applications that include a lot of disk or network access.
We can serve more clients without the need to throw in more hardware and that’s why MEAN applications are highly scalable.
MongoDB lets you develop faster, deploy easier and scale bigger. Real-time applications are more networked, social and interactive than ever. This is driving new requirements to support Big Data, fast feature development and flexible deployment strategies.
Real-time applications require storing more and more data and, more so over, accessing it at higher and higher rates. If your database runs on a single server you will reach a scaling limit. MongoDB scales by adding more servers; you can add more capacity whenever you want.
Modeling data as documents is simpler and allows schemas to evolve effortlessly without duplication. MongoDB works with commodity servers and elastic virtualized environments, saving you money and headaches.
MEAN stack does not come with the bells and whistles of a full stack framework. You can’t compare MEAN to Python Django, Python flask or Ruby on Rails. It’s a web-server technology that you can then use a bunch of different frameworks that exist. If you don’t need that stuff and you just want a bare-bones Web API, Node.js has been around a little bit longer and has a larger community. If you are not comfortable with bare-bones web APIs, you can go for Express.js, which is again a part of MEAN stack.
Depending on how slim you need your server-side API of you real-time applications to be, MEAN can be as slim as you need it to be.
The future is lean; we don’t want bloated full stack frameworks because bloated full stack frameworks are slow and they’re not built with the modern-day client-side library unlike MEAN. You need your server to be lean and efficient and it needs to be serving JSON data. So that these newer client-side libraries can then take it and build your UI from it.
The future of web development I think rests more with MEAN stack and it does with any of the other older technology stacks like LAMP.5/5 (3)
Join fellow entrepreneus! Get TOPS Infosolutions' latest articles straight to your inbox.
Choosing an outsourcing partner for your next mobile…
With more than 1,300 developers and over 94,000…
MEAN stack brings full stack development under purview…
MEAN stack lets you create real-time websites with…
MEAN stack garners interest of many technology firms…
Who doesn’t love the idea of getting their…
In the last blog in React Native series,…
After so many leaks, predictions and speculations, Apple…
Let’s take a look at one screen from…
Magento 2 (M2) marks a new era of…