Micro Frontends Patterns#3: Monolithic Application
Tags: microservices, microfrontends, javascript
Published: 2020-12-17 09:57:56

The first pattern is the so-called Monolithic Application, where the UI, business logic, and Data Access code are managed as a single piece of software.

![](https://dev-to-uploads.s3.amazonaws.com/i/7g1cuxkv0kcizu27pcme.png)
 

The aplication using frameworks such as Ruby on Rails would be a typical example. About Frontend, monoliths can be divided into the following types.

## Minimal JavaScript

This is an application that intentionally uses minimal JavaScript. It has the following characteristics.

* Most page transitions are done on the server side.
* Data fetching and sending are done synchronously without using Ajax or other technologies.
* Screen transitions may be used to switch and interact with the UI
* Lightweight DOM manipulation libraries such as jQuery may be used.

## Partially uses JavaScript

If necessary, the application uses JavaScript partially. However, it does not use the module system or build tools as described below. It has the following characteristics.

* Provides asynchronous communication and interaction by calling APIs with Ajax.
* UI components can be fast and reusable.
* Some implementations include heavy JS implementations which is difficult to modify.
* It is difficult to introduce unit tests for JS, and tends to rely on E2E, which may lead to be fragile.

However, nowadays, ES Module is available even without build tools, and the disadvantages can be solved to some extent (except for IE).

If you don't need complex Frontends, thin JavaScript is sufficient, in my opinion. Of course, quality of the application has nothing to do with the amount of JavaScript. (Increasing the complexity of an application might lead to 'emergence').

## Use built JavaScript

![](https://dev-to-uploads.s3.amazonaws.com/i/746hq90c0hrpporxvxkz.png)


This is a pattern in which JavaScript is built separately from the Monolithic app using webpack, etc., and then mounted for the DOM generated by the template engine. It has the following features.

* Provides asynchronous communication and interaction by calling APIs with Ajax.
* UI components can be fast and reusable.
* Client-Side Rendering can be partially implemented, and a series of somewhat complex features can be implemented.
* Virtual DOM and Incremental DOM provide efficient and developer-friendly DOM manipulation.
* The modular system makes it easy to encapsulate code and write tests.
* The Frontend engineer is free to decide the technology stack, so the responsibilities of the Backend and Frontend engineers begin to be more clearly separated.
* It may get to be difficult to check if the application works in the development environment.

## Modular Monolith

Modular Monolith is a system that divides a monolithic application into 'modules' that are strongly bounded by domains, and tries to combine the best of monoliths and microservices. The key point here is that modules are programmatically unreferenced, so they are different from a simple monolithic system. I won't go into detail here, but if you are interested, you may want to take a look at the following.

- [Deconstructing the Monolith](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity#:~:text=A%20modular%20monolith%20is%20a,enforced%20boundaries%20between%20different%20domains.)

## Pros and Cons

The following is a list of general pros and cons of the Monolithic Application.

### Pros

* Simple architecture and implementation, especially in early development.
* Some applications can be developed by 'one' or a few engineers by narrowing down the technical domain.
* Smaller applications reduce the complexity of redesign when the business domain changes.
* Easy integration or system testing.

### Cons

The disadvantages mainly increase as the code becomes more huge.

* Sometimes the technology stack of the monolithic app limits the other technology stacks.
* The code becomes harder to read and the development speed decreases.
* Less time for a small number of developers, less efficiency for a large number of developers.
* Increases the impact of modifications.
* The responsibilities of the app tends to increase, and what is being done becomes a black box.
* CI tends to take a lot of time, and it tends to be fragile.
* Reliability of the application may decrease.

## Summary

The great strength of Monolithic Application is its simplicity. However, we also found out that it can be a pain.

Also, as for the Frontend, you will notice that the Monolithic Application is not a great fit for the modern Frontend best practices, and is gradually evolving into an architecture which separate Frontends from it. It is really tough to implement the interactive UI in the Monolithic Application. The needs of the application, the needs of the developer, the evolution of the monolith to meet those needs.