Book Image

Modern JavaScript Applications

By : Narayan Prusty
Book Image

Modern JavaScript Applications

By: Narayan Prusty

Overview of this book

Over the years, JavaScript has become vital to the development of a wide range of applications with different architectures. But JS moves lightning fast, and it’s easy to fall behind. Modern JavaScript Applications is designed to get you exploring the latest features of JavaScript and how they can be applied to develop high-quality applications with different architectures. Begin by creating a single page application that builds on the innovative MVC approach using AngularJS, then move forward to develop an enterprise-level application with the microservices architecture using Node to build web services. After that, shift your focus to network programming concepts as you build a real-time web application with websockets. Learn to build responsive, declarative UIs with React and Bootstrap, and see how the performance of web applications can be enhanced using Functional Reactive Programming (FRP). Along the way, explore how the power of JavaScript can be increased multi-fold with high performance techniques. By the end of the book, you’ll be a skilled JavaScript developer with a solid knowledge of the latest JavaScript techniques, tools, and architecture to build modern web apps.
Table of Contents (21 chapters)
Modern JavaScript Applications
Credits
About the Author
About the Reviewer
www.PacktPub.com
Preface
Index

What is monolithic architecture?


To understand microservices architecture, it's important to first understand monolithic architecture, which is its opposite.

In monolithic architecture, different functional components of the server-side application, such as payment processing, account management, push notifications, and other components, all blend together in a single unit.

For example, applications are usually divided into three parts. The parts are HTML pages or native UI that run on the user's machine, server-side application that runs on the server, and database that also runs on the server. The server-side application is responsible for handling HTTP requests, retrieving and storing data in a database, executing algorithms, and so on. If the server-side application is a single executable (that is, running is a single process) that does all these tasks, then we say that the server-side application is monolithic.

This is a common way of building server-side applications. Almost every major CMS, web servers, server-side frameworks, and so on are built using monolithic architecture.

This architecture may seem successful, but problems are likely to arise when your application is large and complex.

Demerits of monolithic architecture

The following are some of the issues caused by server-side applications built using the monolithic architecture.

Scaling monolithic architecture

As traffic to your server-side application increases, you will need to scale your server-side application to handle the traffic.

In case of monolithic architecture, you can scale the server-side application by running the same executable on multiple servers and place the servers behind a load balancer or you can use round robin DNS to distribute the traffic among the servers:

In the preceding diagram, all the servers will be running the same server-side application.

Although scaling is easy, scaling monolithic server-side application ends up with scaling all the components rather than the components that require greater resource. Thus, causing unbalanced utilization of resources sometimes, depending on the quantity and types of resources the components need.

Let's consider some examples to understand the issues caused while scaling monolithic server-side applications:

  • Suppose there is a component of server-side application that requires a more powerful or special kind of hardware, we cannot simply scale this particular component as all the components are packed together, therefore everything needs to be scaled together. So, to make sure that the component gets enough resources, you need to run the server-side application on some more servers with powerful or special hardware, leading to consumption of more resources than actually required.

  • Suppose we have a component that requires to be executed on a specific server operating system that is not free of charge, we cannot simply run this particular component in a non-free operating system as all the components are packed together and therefore, just to execute this specific component, we need to install the non-free operating system on all servers, increasing the cost greatly.

These are just some examples. There are many more issues that you are likely to come across while scaling a monolithic server-side application.

So, when we scale monolithic server-side applications, the components that don't need more powerful or special kind of resource starts receiving them, therefore deceasing resources for the component that needs them. We can say that scaling monolithic server-side application involves scaling all components that are forcing to duplicate everything in the new servers.

Writing monolithic server-side applications

Monolithic server-side applications are written in a particular programming language using a particular framework. Enterprises usually have developers who are experts in different programming languages and frameworks to build server-side applications; therefore, if they are asked to build a monolithic server-side application, then it will be difficult for them to work together.

The components of a monolithic server-side application can be reused only in the same framework using, which it's built. So, you cannot reuse them for some other kind of project that's built using different technologies.

Other issues of monolithic architecture

Here are some other issues that developers might face, depending on the technology that is used to build the monolithic server-side application:

  • It may need to be completely rebuild and redeployed for every small change made to it. This is a time-consuming task and makes your application inaccessible for a long time.

  • It may completely fail if any one of the components fails. It's difficult to build a monolithic application to handle failure of specific components and degrade application features accordingly.

  • It may be difficult to find how much resources are each components consuming.

  • It may be difficult to test and debug individual components separately.