Serengeti logo BLACK white bg w slogan

Micro Technologies for the Development of Macro Applications

Nikolina Tkalec, Mid Software Developer

Microservice Architecture

We've probably all heard of microservices, but to reiterate, microservices are  division of the backend part of the application into several smaller, standalone services. Each of these services has a specific purpose or satisfies a specific business need (payment, sending e-mails, etc.). How many services we will have depends on the application itself and the topic of the application, as well as bottlenecks, which we recognize at the very beginning. Each service is developed, implemented and maintained independently of the other service. Of course, there is a very high probability that these services must communicate with each other, but that is another story. It was first mentioned in 2011.

Micro frontend architecture

An architectural style in which independent applications or parts of them are combined into a larger whole. Division of the frontend part of the application into several smaller, logical, "user-friendly" parts which are called micro frontends. The division again depends on the application itself as well as the previous division of microservices.  Inspired by microservices and resented in 2016.

History of Software Architecture

image 3
Picture 1: History of Software Architecture

In the beginning, we had one team that developed, implemented and maintained the application. As this application grew and new people began to come to the project, more problems appeared. Some of these problems were application scaling, the size of the team which has become difficult to organize, maintaining the application which was not only difficult but also expensive.

Because of all these problems and many others, there was a division into the Frontend and Backend/DevOps team. Such architecture is used today, and that is fine if we do not have problems. But with large applications, we realized that all those problems from the monolithic application were still present and that we did not solve these problems.

Since we first detected the problems on the backend, this is where we came to the appearance of Microservices. With microservices, we have solved most of the problems on the backend, if not all, but on the other hand, we have encountered new problems. Some of the problems were under-fetching and over-fetching data for different client platforms. For example, mobile applications received more data than they requested, while web applications received less data than requested, so they were forced to request additional data. To solve this problem, an aggregation layer has been added, in which the data is processed, so that each client platform receives exactly the data it requested.

5 years later, the frontend team realizes that they are still pulling problems from a monolithic application.  As the backend team successfully solved their problem, following the example of their architecture, Micro fronted was presented. He was the missing link to have independent End-to-end teams, which independently develop, implement and maintain part of the application.

Macro Application Planning – Problems

image 1
Picture 2: Macro Application Planning – Problems

Planning a macro application is one of the essential processes, because it affects the end result, that is, the application itself. When planning, we often encounter problems, and only some of them are: Delivery time? Code quality? What technology to use?

When choosing technologies, we are often guided by IT trends and currently available resources within the company. If we currently have React developers in the company who don't have much work, we certainly won't think about making an application in Vue technology, because it will only be an additional cost.

Of course, sometimes we can find ourselves in a situation where we are not making an application for ourselves, but for a client who is not flexible in terms of technologies, and then we have no choice but to point out potential problems and offer a solution that can solve those problems.

When planning, we are often in a situation where we have developers who work with different technologies, but at the same time an insufficient number of developers in one technology. And when we find ourselves in such a situation, we often either sacrifice the quality of the code so that developers move from one technology to another, or we decide to hire new developers where the process itself can take a long time, thus sacrificing the delivery time.

Macro Application Planning – Solution

The answer to the previous questions is that we do not need to sacrifice anything. If we have developers from several different technologies available, we divide the application accordingly. So, if, for example, we have 20 Angular developers and 10 React developers, we can do most of the application in Angular and a smaller part in React. Micro technologies give us flexibility in the selection of technologies, with a focus on the quality of the code and meeting delivery deadlines. In addition, they allow us to efficiently allocate company resources and allow us to innovate in a way that allows us to extract a small part of the application and try out a new modern technology or enable employees to move from one technology to another and thus keep them in the company.

Macro Application Development – Problems

image 2
Picture 3: Macro Application Development – Problem with the size of the team

One of the problems is certainly the size of the team. With large teams, not only are they difficult to organize, but individuals do not come to the fore.

The size of the project is also a big problem. We all forget what it is like to be a junior developer, and when you are just starting your career and find yourself on a big project in a sea of folders, it can be very frustrating. Sometimes when you find what you were looking for, you already forget why you were looking for it.

Testing an application can take a very long time and the tests sometimes run for hours, which is a big problem.

Maintaining such a large application is not only difficult, but also expensive. Extracting statistics for a particular part of the application is more difficult, and more and more often there are merge conflicts since many developers work on the same source.

Another big problem is knowing the business logic, because every developer should know the business logic of the entire application, which can be a lengthy process.

Macro Application Development – Solution

Instead of one team developing the entire application, micro technologies allow us to divide the application into several smaller units, where each of these unit, i.e. part of the application, is developed, implemented and maintained by a separate team.

Such a division allows us to have less code and thus easier navigation within the project. Instead of running tests for hours, it allows us to release features and fixes much more often and tests to be done faster.

Therefore, it is easier to follow the statistics, because we already have a divided application, and we do not have to spend time learning the entire business logic, but focus only on one part.

Using the app – problems

image 4

It doesn't matter to the users how many technologies and what technologies the application is written in. It's important that the app meets all of their needs.  If you have an application written with bad code, but it meets all user needs and an application that is written with perfect code, but does not meet all of user needs entirely, I am quite sure that the user would choose the application written with bad code. The quality of the code is a problem for the developer and management, not the end user.

This can be a big problem, especially if the competition recognizes it.

Using the app – Solution

image 5
Picture 5: Using the app – solution on multiple servers (source: A typical multi-server architecture | Download Scientific Diagram (

Instead of focusing on technologies, we should focus more on the end user because they will, ultimately, use our product. And if the user is not satisfied, it is a matter of time before it goes to the competition, and micro technologies allow us that if one part of the application does not work, the rest of the application can be used unhindered in most cases.

One thing we all have to remember, and that is that if we don't have users, there is no planning, no development, and ultimately no income, and that is why user satisfaction should come first.


Microtechnologies offer significant advantages in the planning and development of macro applications across management, development, and end-user experience.

Management: Instead of struggling to find experts for a monolithic application, micro technologies allow hiring specialized experts for various frontend technologies, improving code quality and delivery time.

Development: Organizing large teams for macro applications is challenging. Microtechnologies enable splitting the team into smaller, end-to-end teams focused on specific parts of the application, accelerating delivery.

End User: Users care about functionality, not the technologies used. Unlike monolithic applications, where a problem can halt the entire system, micro technologies could enable that if one part fails, the rest of the application remains operational.

Let's do business

The project was co-financed by the European Union from the European Regional Development Fund. The content of the site is the sole responsibility of Serengeti ltd.