{"id":140,"date":"2019-04-23T10:38:06","date_gmt":"2019-04-23T10:38:06","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/welcome-to-the-world-of-micro-apps\/"},"modified":"2021-08-11T16:17:54","modified_gmt":"2021-08-11T14:17:54","slug":"welcome-to-the-world-of-micro-apps","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/frontend\/welcome-to-the-world-of-micro-apps\/","title":{"rendered":"Welcome to the world of micro-apps"},"content":{"rendered":"

T<\/span>he architecture of microservices seems to be becoming extremely popular among backend applications these days. But what about the frontend side? We can clearly see that frontend applications are growing very fast in terms of business logic<\/span> and bundle size. Let\u2019s see what can happen if we try to apply the architecture of microservices on the frontend side.<\/p>\n

I heard about this concept of micro-apps at the conference Codemotion Amsterdam 2019<\/a>. The talk was given by Sander Hoogendoorn<\/a> and it was called \u201cWelcome to the world of micro-apps\u201d.<\/p>\n

Did it mean microservices?<\/h2>\n

Not really. But before we start talking about micro-apps, let\u2019s remember microservices. A few years ago, quite a strong trend started in the backend world; many developers and companies started switching from big monolithic backend applications to so-called microservices.<\/p>\n

Microservice is a very small standalone application which has very limited scope and responsibilities. It usually has separate storage and can communicate with other microservices<\/a> in order to get data from another scope. In this case, the frontend application communicates with each microservice directly or via proxy API (gateway). This concept has a number of benefits compared to the monolithic architecture. You can especially notice them in large enterprise projects. For example, it\u2019s getting much easier to test, maintain and deploy each microservice separately and that leads to more regular and smooth releases. RIsk of breaking the whole application decreases as well. If we check the speed of changes, we might end up with something like this for monolith application:<\/p>\n

\"\"<\/p>\n

Compared to this situation in the case of microservices architecture:<\/p>\n

\"\"<\/p>\n

But at the same time, it becomes more difficult to share common code between the microservices. As always, there is no single right way here, there is a trade-off. Anyway, it\u2019s considered a very common architecture on a backend side nowadays and developers seem quite optimistic about this pattern.<\/p>\n

But what do you mean by micro-apps?<\/h2>\n

If you look at the situation on the frontend side you can see that applications there also become more and more complex and heavy. And it becomes harder to maintain them. Of course, you can say that we have NPM registries where we can publish our custom modules and then use them in projects<\/span>. It helps, but only partially. For example, you can\u2019t re-deploy only your module to see its changes in production, the whole application also needs to be re-deployed.<\/p>\n

And here we come to the idea of micro-apps. It\u2019s relatively simple – taking the microservices approach and applying it to a frontend application. So we want to split our frontend monolith into many different apps, each of them running in a separate process and communicating to other apps, let\u2019s say, by the HTTP protocol. Here is how the frontend architecture will look like then:<\/p>\n

\"\"<\/p>\n

As you see on the slide, our frontend flow has multiple \u201csteps\u201d and each step we consider as a micro-app. We have already defined that, with the micro-apps approach, we\u2019ll have a number of positive effects to the architecture, but how can we actually implement it? Clearly, it\u2019s something new for us, so probably we\u2019ll face some challenges. Let\u2019s look more precisely at what difficulties will appear with the new strategy<\/span> and what options web developers have.<\/p>\n

\"\"<\/p>\n

The main question is quite obvious and wide: how to break up the monolith and what architecture should be in our micro-applications? According to the concept of micro-apps, there are different levels of granularity:<\/p>\n

\"\"<\/p>\n

Following the idea, a monolith should be split by the middle level of granularity, so-called OTOPOP<\/strong> (One Time, One Place, One Person). This level defines features<\/span> and it\u2019s exactly what we need. Each application\u2019s feature will become a separate micro-application.<\/p>\n

\"\"<\/p>\n

Now let\u2019s see how we going to split the micro-app, what its high-level architecture will look like. Here are key parts of the architecture:<\/p>\n