31
I have come across several "new" terms over the internet when it comes to programming. And recently, I came across the term microfrontendon.
From what little I could understand, the idea would be derived from Microservices (which seems to be relating in break the application in several pieces).
I’d like to know:
20
What would be Microfrontend?
Summarizing well and knowing what web Components are, each component of the UI, can be a separate project, with its own dependencies, structure and team of developers
What problems he solves (or does not solve)?
It even solves some very specific situations, but brings several other problems with it. So it should be analyzed well the context before adopting.
What are the pros and cons?
If you have an interface that is mounted from several projects...
There is a build-up of dependencies, much of it may be just a small change of version or different libraries with the same function (for example, the same screen having to load Vue and React)
You need to manage status between projects, which will likely add another dependency
You shouldn’t have global variables among all projects, after all, each project should be decoupled from the others
All this implies greater complexity
But she helps something...
Allows the use of different libraries in the same application (in this case a website and not a project)
Although it increases the complexity of the whole, it simplifies its parts, as it divides that monster into smaller projects
Possible cases of use:
Allows migrating the main library/framework (or only version of it) gradually, you can go one component at a time
In very large applications, the project and its respective teams can be better divided, decoupling the parts
Observations for use cases, respectively:
If the migration process is fast, it is probably not worth adding just this temporary complexity
The splitting of the project can be done through different applications without using microfrontend, as long as they use the same library/main framework or the common dependencies have support for all. For example, I may have an application on Rh.app.com made in Vue and financial person.app.com made with Angular, both using Ionic
Other comments
At the time of this response, I would say that the microfrontend is still crawling, so there are not so many materials and are not yet well developed
Although it allows you to create a screen with several projects, it is good to avoid, especially when there are many different dependencies between them
If your application is medium or small do not use, need a very strong reason even to make sense of its use
In podcast linked in comments by hugocsl, is discussed on the problem of having too many dependencies, one of the solutions is to combine with the team(s) to use as many common dependencies and, when updating, all update together, but this makes little sense, since it practically ends the advantages
To avoid duplication of dependencies, that is, multiple projects load the same things, they must be loaded by a global manager (above the project), it will check if it is necessary to load it. At first I see nothing but this, except of course, the increase in complexity
A quick conclusion
If you have a screen that uses multiple "repeated" libraries/framework (with the same function), possibly there is a bigger problem, the disorganization/poorly structuring of the application/team, ie, the application has changed (grew, decreased or changed the scope) and that dependency is no longer sufficient, needing others and accumulating or else the team is not organized or is not properly empowered, can not change your stack (which should be simple)
I find it hard for anyone to look at a project and say, "This has to be microfrontend," the problems it solves, for the most part, can be solved in other, simpler ways. Most likely, there will be plenty of people wanting to adopt for no real reason, just following the herd. Also has the same problem of Microservices, people want to adopt but still use FTP
17
The Micro Frontends is a technique that has emerged to deal with the complexity of large frontend projects, where in the same system we can merge different front-end technologies (Angular, Angularjs, React, Vue, etc.), maintaining independent deploy and maintenance.
You can see a demo of a solution mixing various technologies here: https://single-spa.surge.sh
It arose to solve a problem similar to what micro services came to solve on backend: the software monoliths. Long ago it was noticed that large frontend projects faced the same problems over time: difficulty in maintenance, difficulty updating libraries, unforeseen impacts at different points of application, impossibility of using a newer library within the same application, difficulty of different teams working in the same application, etc.
Separating the frontend into smaller applications made it possible to overcome these problems.
To illustrate a common architecture, we have below a monolithic frontend:
With the introduction of Micro Frontend in the application, it can be worked as follows:
Here is another example illustrating how different teams could participate in development independently, on the same screen:
As stated earlier, the screen can be segmented into different parts, mixing the technologies. In the example above we have the area circled in red in Angular, the circled in blue uses Reactjs and the circled in green was made with Vue.js.
Until recently there were no widespread solutions on how to solve this problem. The subject became popular and gained quite dimension after the Thoughworks and Martin Fowler further explore the subject, so much so that the main references to the subject on the Internet are linked to them.
What are the pros and cons?
Until then I listed the pros.
The main counter, in my view, is when these independent parties need to "talk" in some way. That is, they need to share information. There are solutions for this too, but it is not something so trivial to do if compared to a "monolithic" solution, because the degree of difficulty will depend on what information you want to be shared.
Another problem is the size of requests, which increase. Imagine that, for example, you are using the Bootstrap in more than one micro frontend in your application. In this case we will have the same library being loaded more than once. There are ways around this if necessary.
You also need to assess whether your team/project/company is able to handle different front-end technologies, not only because of the language itself but also the more "structural" differences: repository, deploy, versioning, etc.
I remembered this image, I just couldn’t get the source back in time
Browser other questions tagged terminology
You are not signed in. Login or sign up in order to post.
Related: What is a microservice architecture?
– Wallace Maxters
From what I understand, it’s a way of separating concerns. Each team of a piece of the front-end works separately, in a defined place of the screen, without needing high-coupling between them. When a message arrives (whether it comes from some event on the server screen or response), a bus distributes to all "microfronts" registered and they update themselves with this information. It’s been a long time since I’ve seen this concept, but that’s what’s in my memory
– Jefferson Quesado
I wanted to make a joke like the old days of Sopt, but I’d be censored, so never mind...
– Maniero
There’s an article by Cam Jackson on Martin Fowler’s website Micro Frontends is worth reading. It is in English
– David
You can create every feature in the front end with the new framework of the week q provides greater flexibility :P
– rray
@rray, and this is something very valid? Or is it one of those hypothetical advantages that when you try to use have more headache than results?
– Jefferson Quesado
Other than hypothetical, it should be obvious that it only makes sense in mediocre, monster-sized teams, right? For some reason everyone will be cheating. Want to bet that dev solo will adopt? almost all project organization techniques were created in response to the mediocrity of devs, it is confession of incompetence, starting with OOP.
– Maniero
I can’t believe something like this could work, and I’m trying really hard to see how that could be useful, but it’s hard. Just the fact of accumulating the core of several frameworks/libraries should already end the idea, at least restrict to 2 or 3 frameworks/libraries. I see many problems and almost no solution
– Costamilam
@Costamilam listen to this will interest you https://hipsters.tech/microfrontends-hipsters-164/
– hugocsl
@hugocsl thanks for the link, after listening I can better understand the use cases, I risked an answer based mainly on it
– Costamilam
@Costamilam yes it is very interesting the topics addressed there, for whom eh layman as I have given to have a better idea of things. []’s
– hugocsl
Expensive in the Micro Front End the idea is to separate the front-end application into many smaller layers where each being is responsible for a specific part of your application.
– Abisai Santos
WARNING: The purpose of this technique is to allow large teams programming can achieve results even being composed of members who have experience in incompatible Frameworks . Don’t try that in SOHO
– Augusto Vasques
@Augustovasques plus large teams, I would cite in large (and/or old) front projects. Many old projects may have problems with the language/framework adopted: lack of professionals, limitations, difficulties, etc... anyway, some new need arises in which the current language/framework does not meet well, the legacy needs to be maintained and it is impossible to migrate across the front.
– Dherik