Microservices approach in a typical Vue application

How can we transform a simple monolithic Vue application into a Micro Service approach?

Over the past years, the approach to the development of frontend applications has changed significantly. Application development has been dominated by various frameworks like Vue, React, Angular. With the growing popularity of frameworks, the approach to architecture and production of such applications has also changed. Patterns and programming paradigms usually used in backend started to be adapted for frontend architectures. The transformation of the current frontend is drastic, but definitely this change has gone in the right direction.

The biggest flaw in framework-based applications is their monolithic structure. Such an application provides us with a specific solution that works great and solves the assumed business needs. Unfortunately, all this is closed in one indivisible application, in which everything is connected with each other and business contexts are not separated.

Fortunately, we already have a solution to this problem — we refer to the architectures called “Micro Frontends” and “Microservices”.

Microservices & Micro Frontends

These architectures are such extensive topics that I have no intention of elaborating on their detailed functioning here. I just want to briefly explain the concepts and assumptions of this approach.

These two terms are very interrelated because both approaches focus on building modular architecture. This is an architecture made up of small parts that work together to provide a fully functioning solution. Such modules can be independent or have connections, which allows for logical arrangement of applications in context.

Microservices

This style of architecture is closely related to Service Oriented Architecture (SOA). This approach allows you to arrange applications from small modules that:

• divide applications into business contexts,
• can be manufactured in small teams,
• are easy to test and maintain,
• are loosely connected,
• are independently implemented.

Micro Frontends

The concept comes from the architecture of “Microservices”, but is adapted to the frontend world. The idea of this solution is to treat the web application as a set of functionalities that can be shared between teams. The teams are independent and cross-functional and have the ability to choose the technology as they see fit.

This approach allows backend and frontend teams to share one independent business context and not worry about others.

Monolithic Frontends:

Micro Frontends:

What we needed and why?

“Micro Frontends” is a great thing, and certainly the use of this kind of architecture will bring many benefits when developing applications. However, sometimes we don’t have to use all the mechanics of the approach, because the project may have some limitations, the business model does not allow it, or possibly the choice of technology gives some limitations.

The Ergonode application is such an example. This is a PIM (Product Information Management) application, which is developed in an open-source approach. The project has a frontend and backend as separate running systems communicating through API. The backend used microservices from the very beginning, while the frontend, as it uses the Vue framework, had a typical monolithic structure.

Over time, however, business needs put us in a situation where the approach to “Microservices” architecture becomes one of the best solutions to meet all our assumptions.

Ergonode assumptions:

• Fully modular application — apart from functionalities created by the core team, we want to allow other developers to create their own modules extending the mechanisms of our application. It’s not easy, because you need to properly prepare the architecture for such extensions, not only from the backend, but also from the frontend.
• Core of the application remains unchanged — extensions and modules do not affect the code written by the core team. Modules can use solutions already implemented, but they cannot modify them.
• Module versioning — each module should be delivered in releasable versions. Customers should have a choice whether or not to upgrade a module, and the package update process itself should be very simple.
• Simple module management — modules can be localised and hosted in external npm services. Installation and uninstallation should be a smooth process.
• Stay with Vue — as the application was developed on the Vue and Nuxt frameworks, we want to continue using these technologies and not add any more unnecessary libraries if possible.
• Simple addition of modules — a very easy process of creating a new module and smooth communication between the modules.

Solution

All the problems and needs led us to a situation where we decided that the best solution would be to write our own library to help create “Microservices” architecture using Vue and Nuxt technology. This allowed us to stay with the technologies we used and not add new unnecessary frameworks. We decided to transform the written solution into a library npm, so that it could serve other companies facing similar problems.

That’s how the VueMS library was created.

@ergonode/vuems

Our solution is based on the built-in mechanism of Nuxt modules in order not to modify the basic operation of the framework. The mechanism is closely related to Vue and was created only for this framework.

The main task of the library is to transform the monolithic approach to Nuxt architecture into a modular one. Of course Nuxt allows you to expand your mechanisms through external modules, but unfortunately they have their limitations. Often these modules are single components, directives, plugins that probably add mechanics to the system, and our need was more complex.

We needed each module to have a structure similar to a large application, so that its directory layout and mechanisms would not differ from a large monolithic application. More specifically, each module could have its own pages, its own routing, its own components, plugins and everything that every Vue + Nuxt based application has. The module would have no limits, so it could contain huge functionality as well as a single component or plugin.

These mechanisms allow for loading modules located locally in the project and modules downloaded from external services such as npm. This allows you to version the modules and update them whenever needed. The packages hosted on the npm are thus resistant to modifications and only creators can change and update them. If a base module does not meet the customer’s expectations, it can be easily replaced by its own solution.

Communication between individual services was also an important element. We used alias mechanisms, thanks to which communication is simple and very clear. We also have the ability to determine which modules are required and whether the services have relations between them.

Summary

With this approach we can easily separate business contexts not only on the backend side, but also on the frontend side. The modules can be written by separate teams, which have separate tasks. The base application code is maintained and unchanged, and only the main team has the ability to modify it. The client’s instances are independent and can be easily expanded and the installation of finished modules is very simple.