Message brokers, sagas, cutting of specialties, now UI snippets - is that necessary?
Even if some oldschool backenders still don't quite want to believe it, front-end development has outgrown its infancy. Long gone are the days of JavaScript snippet hunting combined with a bit of pixel pushing. On the contrary, it's not uncommon for the real value creation to take place on the front end.
Why am I telling you this? Because time and again in projects I experience that frontend, and thus UI integration is taken lightly. Yet UIs are the places where we bring together the different strands of capabilities we want to offer our users.
I can't blame any backendler (m/f) when even the master Yoda of backend development, Uncle Bob, in his latest work ("Clean Craftsmanship - Best Practices, Standards and Ethics for Software Development", publication date: May 2022 ) says the following - against the background of his otherwise excellent TDD chapter :
"Don't test GUIs.
Test everything except the GUI.
The GUI is smaller than you think.
Let's look at the third rule first. The GUI is much smaller than you think. The GUI is just a very small part of the software that displays information on the screen. It is probably the smallest part of the software. It's the software that sends the commands to the engine that paints the pixels on the screen."
(Robert C. Martin, src: https://learning.oreilly.com/library/view/clean-craftsmanship/9783747504185/Text/04.html#:-:text=Testen%20Sie%20keine%20GUIs,auf%20den%20Bildschirm%20malt; offline: Kap. 4.2 „Test user interfaces“)
With all due respect to the great Uncle Bob and his wisdom gained from experience, I think he is wrong here.
In my opinion, this point of view is not only antiquated but also dangerous. Inconsistencies, old-fashioned design and long loading times when building the user interface are a no-go for many end customers.
In the inspiring software architect podcast from Heise, Eberhard Wolff puts it in a nutshell in a conversation with Stefan Tilkov in the current (as of 2023/05/05 - 13:56) episode:
Software that is not user-friendly will be hated by users.
There may be exceptions, especially if users have been conditioned to a "complicated" user interface and/or the product has a (quasi-)monopoly position. Otherwise, however, user interfaces that are difficult to use are an abomination for most users.
And as Eberhard Wolff also aptly points out, it is not enough for usability that framework X was used (X ∈ {Angular, React, VueJs, Sveltje and Co.}).
This is primarily the responsibility of UI/UX designers, not us developers and/or software architects.
Microfrontends are not equal to Microservices, but what are Microservices?
I refer completely unselfishly to my blog article regarding the definition of microservices:
For this noble gesture, I nominated myself for the Mother Theresa Award. Since the jury there told me that I would have little chance with such an action, I will give you a few more sources. Gritting my teeth. At the end of this article are all my sources used for this article. There you will also find definitions. But after that, please inform the Mother Theresa Award jury immediately....
Microfrontends : a definition of terms
One thing is important: Microfrontends is not a client-side technology, but an architectural style.
Microfrontends (MF) are the technical representation of a business subdomain, they enable independent implementations with the same or different technology. Since this also applies to (backend) microservices, the term MF should be further restricted: In an MF architecture, the application is composed of several independent web user interfaces that are brought together in the browser in an integration layer. This is necessary because there is always only one document for the browser, which it initially loads from the server.
Are microfrontends equals to microservices in the frontend?
No.
MFs are a form of architecture similar to microservices, but they operate in a different, limiting environment.
Namely, that of the browser.
The key difference between front-end and back-end is that the browser runs an application as a single instance, while back-end services operate independently. This has a great impact on the scalability and robustness of the application. In the frontend, there is only one main process, which is lost in case of a crash, while in the backend, crashed services can be easily replaced by new instances.
Disadvantages of microfrontends = a paean to the UI monolith
What do you mean Contra? Monolith is always dumb, isn't it? Go away, novelty bias!
I am a big fan of Stefan Tilkov (I must have mentioned him 100 times on this website) and I consider the InnoQ consultants I have met so far (one of them is my architect colleague at my current client, as of 2023/04/02 - 10:25) to be far-sighted and competent IT strategists.
But I vehemently disagree, with Stefan Tilkov's two younger colleagues in this InnoQ podact episode:
https://www.innoq.com/de/podcast/054-microfrontends/ ( last visit 2023/03/23 – 22:01)
Stefan asks from minute 2:49 if sometimes a monolithic frontend could also be okay. The two colleagues (m & w) answered in the negative.
In my opinion, Stefan doesn't see it that way during the recording of the episode and tried to tease out a few "pro-monolith" tones from them. He pointed out to his colleagues - quite rightly - that most of the software in use does not have microfrontends screwed onto the digital grille.
The arguments that came next seemed to me half-hearted and rather dutiful to Stefan. I may be wrong here, but it sounded that way to me.
I think the novelty bias was at work here, which many young colleagues and - ashes on my head - also my former self (referring to a time several years ago when I didn't have a white stubbly beard) knew how to catch as easily as the sweet songs of the seductive Loreley.
How does the bias make itself felt?
As soon as a new technology appears on the horizon - even if it is only one that comes in a new bottle, with the old wine still flowing underneath - people argue - sometimes unconsciously - against the old and in favor of the new.
What is the novelty bias?
In psychology, novelty bias is the tendency to attribute more attention and attractiveness to what is new or unfamiliar compared to what is old. As a result, people often tend to view new technologies as superior to older technologies, even if this is not always the case.
Do you work with ChatGPT? I use Mastermind for various creative things. By the way, I don't have blog posts written for me, because as you can probably tell, I have my own style. Besides, writing is fun for me. But I also write a bit of fiction on the side (on a dime novel level), right now a werewolf novel (Stephen King, dress warmly, your Tarker Mills wolf has had its day!). That's when I like to have (minor) characters crafted according to a character cheat I've designed. And every time I rate the design as bad, ChatGPT suggests a new text. And although I know the novelty bias, I always catch myself "blindly" rating and accepting the "new" draft as better. So our "new-is-better" delusion runs pretty deep.
Why are we subject to this novelty tendency?
People are curious by nature and seek new experiences and information. New technologies can satisfy this need by giving us the feeling of being up-to-date and keeping up with the times.
People often compare themselves to others to assess their own social status and capabilities. A new technology can make us feel more advanced or better equipped than those using older technologies. This can boost our self-esteem and lead to a preference for the new.
People also tend to seek information that confirms their existing beliefs and expectations (= confirmation bias). If we believe that a new technology is better, we look for information that supports this assumption and at the same time overlook counterarguments or evidence that suggests that the old technology might be just as good or even better.
People also have a tendency to believe in progress and assume that newer technologies must be better than older technologies because of research and development. This assumption is based on the idea that technological advances always bring improvements. However, this can be misleading in some cases, as not every new technology is necessarily better or offers significant improvements over older technologies.
To the point:
The new is far from being the better of the old.
It's the added value that counts! Welcome, filthy lucre!
One more aspect should be mentioned here. I have already hinted at it in the preceding paragraph:
So far, it worked without microfrontends. And it did it damn well.
I've seen legacy applications that have lost some of their sex appeal over the years. Despite the somewhat scratched facade, there was still a money printing machine running in the basement. Instead of code senior pencil, these were the cash cows.
This is an important point that I often overlooked or wanted to overlook in the past.
If the code was "ugly", the code was "crap" for me, had something sinful about it and belonged to be eradicated by the clean-code paladin, no matter what the cost.
That this ugly duckling brought more revenue to a company than any Brad Pitt or Angelina Jolie formed from bits and bytes, which consisted of polished interfaces, loosely coupled components and sophisticated unit tests, I didn't get in my youthful delusion.
But that's exactly the point:
To create value.
Do you understand what I'm trying to tell you?
The most important thing is the customer benefit. And not your (or my) puffed up ego!
This is not to say that every junk code meets my approval, on the contrary, it still hurts my soul as a code aesthete when I see such a pile of glued spaghetti (mostly I see it as an architect rather than a spaghetti mountain).
And poorly maintainable code always costs more money than clean code, thus reducing customer value, i.e. revenue. Almost everyone knows that nowadays.
BUT: This often only becomes noticeable with a time lag. And then it has to be weighed up whether and when a refactoring of the entire codebase pays off. We developers can (and must) provide the information for this, no question. Unvarnished, unadorned. But the decision is made by those who also bear the economic risk. And that's usually not us, unless it's about our own code, e.g. as startup founders.
And even there (with startups), I see time and again that tests are dispensed with because the market pressure is too great. The temptation is great to point out these shortcomings as an outsider with the clean code pointing finger. However, I only grant authorization to those who have already done things better in the same situation. And could not do better, if the wind had been favorable ...
There are people who pay well, who pay badly, people who pay promptly, who never pay, people who pay slowly, who pay cash, who pay off, who pay on top, who pay back - only people who like to pay do not exist.
(Georg Christoph Lichtenberg)
Other disadvantages
COMPLEXITY IS SHIFTED
The complexity of individual services decreases. No question about it. But like the evil spirits in horror movies, it just looks for another host. It slips into the overall application. Strictly speaking, it moves into the interaction/communication layer. And to the deployment floor. The coordination and integration of the various microfrontends is considerably more complex than with a monolith. And with a small number of MFs, this can sometimes eat up any other form of return from MF.
OVERHEAD
Since each MF is loaded and executed separately, this can lead to higher overhead. Especially if an application consists of many microfrontends, the number of resources needed to execute and load the application will increase. And only when there are many MFs is this architectural approach also worthwhile.
COGNITIVE LOAD IS SHIFTED AS WELL AS COMPLEXITY
First of all, the evil spirit disappears...
For the frontendler who "only" moves within the marked path of a MF, the complexity is reduced significantly.
Instead of trudging through the entire, gigantic Angular application with its 3 proprietary migration modules (from AngularJS to Angular) and the associated anti-corruption layers, with MF it is sufficient to focus on a specific MF.
...to reappear elsewhere....
However, the evil spirit of the cognitive load does the same as its cousin, the complexity demon: It slips into another host. Into the heads of the developers who (have to) deal with infrastructure and coordination / orchestration. Into the heads of those through whose veins more DevOps blood flows. From now on, they will be responsible for splitting the frontend application into several microfrontends. And that requires precise planning and coordination to ensure that the application runs without errors even under heavy load. There is also a risk of knowledge silos forming here.
PERFORMANCE
Yes, you read correctly. Using multiple microfrontends can affect the performance of the application. For example, if the number of microfrontends is too high, it can slow down the application.
Advantages of microfrontends = A lament about the UI monolith
INCREMENTAL UPGRADES
MFs improve the possibility of incremental upgrades by enabling a decentralized architecture. Each MF can be developed, tested, and deployed independently of the other front ends. This allows teams to upgrade individual parts of the application without impacting the rest of the application.
No more coordinating with the other teams to perform a major upgrade.
The dependency between frontend and backend development can also be reduced, as teams can upgrade their frontends independently of the backend services, as long as they adhere to the defined APIs. This enables faster development and deployment of updates, as teams can implement changes more quickly and shorten deployment cycles.
SHIFTING OF THE COGNITIVE LOAD => IF NECESSARY FASTER ONBOARDING
As already mentioned, there will probably be a shift in the cognitive load. Away from the pure front-end workers, towards those who also have infrastructure tasks.
For the relieved, this can have the consequence that the onboarding of new team members is made easier and that especially junior employees are relieved of the fear of the indomitable Frotend monolith. This is a great advantage for employers when it comes to recruiting new developers.
REUSABILITY
MF can be reused. This significantly reduces the effort required to develop and maintain components. It also allows microfrontends to be quickly adapted to new requirements or customer needs. Whenever a new face shows up in the marketing department, the design ideas bubbling up from over-motivation (new logo, new colors, heck, it's all new) can be quickly implemented by plugging together the configurable components. {Tip: Tag the old state on Git with "ToRecover." Because once the CEO has time to look at the redesign in peace, it will be rolled back anyway...}
CONTAINERIZATION => SCALING AND ROBUSTNESS ++
Similar to microservices, microfrontends offer the advantage that they can (should!) be easily containerized. This allows microfrontends to run independently of the underlying infrastructure and to be deployed in different environments with less friction. Scaling and robustness can be increased as a result.
It can also make orchestration and management easier.
The emphasis is on "can." Because those who are not familiar with Docker and Co. can quickly create more pain than relief here. This should be included as a warning. Key point: Shifting the cognitive load in the direction of infrastructure.
FLEXIBILITY IN TOOLING
Not to be neglected is the possibility to select the best tool for a task in a MF architecture.
A few words of warning here as well: In my opinion, a multi-framework approach (VueJS, React, Angular and co.) only makes sense in {very, very, very} few cases:
- When you're dealing with legacy systems where frontend decisions have been made that can't be changed for technical and / or business reasons.
- When one has made a conscious decision to migrate to a different UI framework.
- If one integrates third-party systems and has to accept the front-end decisions already made here as well.
Otherwise, I personally {very, very, very strongly } advise against growing a UI framework zoo.
What to always pay attention to when implementing microfrontends
It is not uncommon for the conception phase to be followed by the "rewrite" phase. Everything that was planned is then overturned, because it was not considered that Kuddel and Tina would not fit into a new team due to the risk of permanent disputes, because it was not considered that a fancy build and release strategy cannot be implemented with the limited number of virtual machines hosted in the company's own data center. In short: Because it was not considered that the software architecture designed in the ivory tower does not match the organizational realities in the company.
In the case of a microfrontend architecture, it is particularly important to check the framework conditions in advance to ensure that the division of services and teams really works and that neither Conway's Law nor outdated infrastructures stand in the way of implementation.
The Microfrontend flavors at a glance
Server-side approaches
Ajax and roundtrips = transclusion
If you're of the older age, like me, then you might remember the hype around AJAX. The first big "wave" that washed away Javascript's "snippet bin" image. AJAX stands for "Asynchronous JavaScript and XML." Jesse J. Garrett, a consultant at the American company AdaptivePath, introduced the concept in an article in 2005 and immediately included a flashy marketing acronym. And that doesn't even fit, because XML was only rarely used and also asynchronously the whole thing doesn't always have to run. Only the J for Javascript fits. Just remember: AJAX is a technique that allows to execute HTTP requests in the background and to load dynamic content into a web page without having to reload it completely.
But now how does this fit with microfrontends? Well, there is a server-side approach to microfrontends, also known as a transclusion pattern. Here, the HTML code of the microfrontend is generated on the server and sent to the browser as part of the page. This means that the microfrontend codebase and the backend codebase are merged, resulting in a seamless interaction.
Transclusion is a type of server-side includes (SSI) where the server dynamically inserts HTML fragments into other pages. In the context of microfrontends, this means that the server generates the entire HTML fragment for the microfrontend and inserts it into the main application. The browser then gets a full HTML document containing the microfrontend content.
- (see in detail about the pattern - https://www.innoq.com/de/podcast/046-transklusion/ - last visit: 2023/04/20 - 21:11)
- (see about the origin of the term "transclusion" - https://de.wikipedia.org/wiki/Transklusion - last visit: 21/03/2023 - 16:11)
Advantages
By integrating content into the existing DOM rather than simply embedding it in an iframe, the result is a more natural document flow. Everything looks more fluid.
In terms of search engine optimization and accessibility, the transclusion pattern also has advantages over some other approaches. Although the content is added after the page loads, it is recognized and indexed by search engines. This makes the page easier to find and more accessible.
Disadvantages
One of the disadvantages is asynchronous content loading. How now? - you might be asking yourself right now. Just now you said that asynchronous request-in-the-background firing would make everything smoother. And now this is suddenly supposed to be a disadvantage?
You're right, I should be more specific: It CAN be a disadvantage. Because when content is loaded asynchronously, it means that the browser doesn't load the content directly when the page is loaded, but afterwards. This can cause latency before the content is visible on the page. If this is large enough, it can affect usability. Especially for pages that require a lot of content to load, this can cause a noticeable lag effect.
When I think of all the integration meetings I've been through.... Those meetings will have to be held again with this approach. This is because the Ajax model does not include isolation, and as a result, namespace conflicts can quickly arise between teams. In addition, the team to which a particular fragment is to be assigned must know when its code is to be executed. This also requires coordination with the other teams to ensure that all fragments run smoothly.
Another challenge is the round-trip latency inherent in all server-side approaches. This hurts especially when the network conditions are not optimal.
Template Composition
In the server-side template composition approach, each micro frontend represents a separate, self-contained domain concept. This means that the individual parts can be developed and deployed completely independently of each other. How exactly the different HTML files end up on the web server is irrelevant for the time being. The only important thing is that each has its own deployment. This further strengthens the independence of the individual micro front-ends. For even more independence, you can even have a separate server for rendering and deploying each micro frontend. There is then one server at the top that makes requests to the other servers.
Advantages
A server-side template composition offers several advantages. For one, it avoids browser security issues (CORS) and allows sharing of data such as login status through cookies. If the network connection is good, excellent first-load performance can be achieved because the browser receives a page that has already been composed. In addition, server-side template composition is a proven and well-tested technology (SSI and ESI). While this doesn't mean it's always easy to configure, once the system is up and running, it requires little maintenance. It also works well for search engines and accessibility.
Disadvantages
Offline troubles and lousy network connections can affect the loading process. There are also limitations with user interactions, as it is only possible to respond quickly to user input with additional client-side integration approaches such as Ajax or web components. And without isolation, there can also be a lot of tuning overhead, see also at Ajax & Roundtrips.
API-Gateway
An API gateway provides the single point of access for all clients. The gateway can handle requests in two ways. Some requests are forwarded to the appropriate service. Other requests are handled by fanning out to multiple services.
Instead of providing a single API, the API gateway can provide a different API for each client.
The API gateway can also implement security features, such as verifying that the client is authorized to execute the request.
Advantages
One of the biggest advantages is the simplification of communication between microfrontends and backend microservices by providing a single interface for different services. This allows developers to access backend services and use their data and functions in a standardized way.
Furthermore, API gateways provide an additional layer of abstraction that hides the complexity of the backend infrastructure like a facade, making it easier to develop microfrontends.
Another very big advantage is the security that API gateways provide through mechanisms like authentication, authorization, and protection against attacks like DDoS. However, and we'll get to this in the disadvantages, this luxury doesn't come for free, of course.
API gateways can also provide features such as caching, load balancing and data compression to improve the performance and scalability of microfrontends.
In addition, API gateway monitoring enables very accurate tracking and analysis of requests to the microfrontends to quickly identify performance issues. Whether they can then be fixed just as quickly is another story. Read on ;)
Disadvantages
When it comes to the downsides of API gateways, it's worth mentioning that they can bring a high level of complexity to initial setup and troubleshooting. For example, one customer had an Azure API gateway bug that - due to a misconfiguration on our part - delayed access to the services behind the gateway by up to 45 minutes. On every call, mind you! A real challenge that could only be solved by experts with excellent Azure knowledge. We weren't. I.e. we had to ask the DevOps team for help and as it always is with special units in projects (be it DevOps, who are supposed to be in the Scrum team but almost never are; be it UI/UX designers): They are "overbooked" and our request ended up on the waiting list.
Also, the gateway can act as a single point of failure and thus a bottleneck, causing latency issues.
Add to that the fact that using API gateways can come at a high cost and you may be exposing yourself to a vendor lock.
The steep learning curve must also be taken into account.
BFF – Backend for Frontends
BFF stands for backend for frontends and is - strictly speaking - a special kind of API gateway. Here, a separate backend is defined for each client type, which is addressed via the API gateway or another "traffic policeman" (or somewhat hipper: dispatcher). This has the advantage that the backend can be tailored specifically to the requirements of the client in question.
For example: a mobile app may need less data than the desktop version. With a BFF, the required data can be provided specifically for the app without the desktop version suffering.
Advantages
On the one hand, BFF leads to decoupling and modularity. This means that each microfrontend and BFF can be developed, tested and deployed independently, which increases the flexibility and scalability of the overall system.
By optimizing performance, requests from microfrontends to the backend can be targeted by retrieving and processing only the data needed. This reduces overhead and improves application performance.
In addition, microfrontends and BFFs promote collaboration in small, autonomous teams. Convay's Law says hello.
They also offer flexibility in the choice of technology. But beware: zoo danger! Vue, React and angular may make a fancy team, but the friction on the human side stands in the way. In addition, as a project manager, you risk being dependent on the currently (as of 2023/05/11 - 18:54) tight labor market to an even greater extent than is already the case.
Disadvantages
One disadvantage is that the complexity shifts to interaction and communication between different services. As the number of services increases, so does the deployment effort, which can become very hard with the use of oldschool scripts. Also, "synchronization" between microfrontends and BFFs with messaging, using sagas if necessary, can be a challenge.
Another disadvantage is redundancy and inconsistency in data management, as true consistency creeps in only gradually (eventual consistency).
Communication between microfrontends and BFFs can also add network latency and overhead and impact performance.
In addition, due to the delegation of the choice of technologies and tools for microfrontends and BFFs to individual teams, there may be difficulties in integration and collaboration between different teams. And as mentioned in the previous section: The larger the technology zoo, the greater the coordination effort.
Client-side approaches
Procedures feasible at build time
Separate webapps connected with good old links
One way to implement microfrontends client-side is to create separate pages for each sub-application and connect them via (nothing but) links. This is the loosest form of linking.
Each page can bring its own set of HTML, CSS, and Javascript.
The Pages may (but do not have to) be hosted on a common domain for ease of management.
Pages can be connected via links or routes, depending on how you want to navigate between the sub-applications.
Advantages
As loose the coupling, as easy the implementation.
Each team can manage its own releases and deliver continuously without impacting other teams.
This method also makes it easier to scale the application.
Because each microfrontend is developed and operated separately, individual parts of the application can be expanded or scaled back as needed. This keeps the application flexible and adaptable to different requirements and user numbers.
Disadvantages
One potential disadvantage of microfrontends connected by separate pages is the risk of inconsistent UX. Since each microfrontend is developed independently, this can lead to users feeling like they are looking at a motley pile of UI.
In addition, loading each page can lead to high roundtrip latency. The patchwork can then be compounded by regular page freezes at worst.
In addition, each page may have its own dependencies, leading to redundant dependencies and an overall larger application.
A problem often encountered in practice is that of shared resources. Sharing state and data between pages is almost always a challenge.
Now don't tell me that nothing needs to be shared on your end. I hear that a lot. My counter question then is usually: Then why do you want to make ONE application out of it? In addition, most people only realize how strongly their applications are coupled when a consistent separation is made. It's like analog life: You don't realize you've used something (or someone) until it's gone.
Integration at the Package.json levelIntegration at the Package.json level
One approach is to publish each micro frontend as a package and have the container application include them all as library dependencies.
Advantages
One advantage is that each micro front-end application can be developed and deployed as a standalone unit. This allows each team to manage and continuously deliver its own releases without impacting other teams.
In addition, integration via package.json enables better scalability. The container application can be more easily adapted to growing requirements by expanding or reducing individual packages as needed.
By using Node.js and the package.json file, tools such as npm or Yarn can also be used to manage dependencies, set up test environments and create builds. This greatly simplifies the development and implementation of micro front-ends and ensures higher quality and stability of the overall system.
Disadvantages
However, this approach means that we have to recompile and release every single micro front-end in order to release a change to a single part of the product. Just as with microservices, I've seen that such a lockstep release process can cause a lot of pain. After going to the trouble of splitting our application into individual codebases that can be developed and tested independently, lockstep would be reintroduced through the back door in the release phase. Albeit on a different level, but not necessarily less problematic because of it.
Since each dependency must be released and downloaded as a package, this can add more overhead and impact the overall performance of the application.
If multiple dependencies require different versions of the same package, this can lead to version conflicts and inconsistent behavior.
Procedures executable at runtime
Integration via iFrames
iFrames are sort of the Babushka dolls of the Internet. You know, those wooden dolls that you put inside each other. Only digital. So a window within a window within a window.... This makes it possible to seamlessly integrate content from other sources into a web page. And without having to leave the page. iFrames are often used for advertising, embedded videos or external content like maps or widgets.
Advantages
iFrames are like storefronts where MFs can live without getting in each other's way. Thus, the isolation is quite good.
iFrames also offer an advantage in terms of security, by restricting access to the higher-order DOM and the main page's resources.
But that's not all. iFrames are also more flexible than their age gives them credit for: they allow seamless integration of MFs developed in different technologies and frameworks without the need for extra tools or customization.
Disadvantages
iFrames can cause performance degradation. This is because each iFrame loads its own environment, including JavaScript and CSS. This can lead to longer load times and a slightly worse user experience.
Another drawback is that communication between the microfrontends in iFrames and the main application can sometimes be difficult. They have to rely on PostMessage APIs or other indirect communication methods, which can make state management and data sharing difficult.
Finally, iFrames can make responsive design more difficult to implement. They have fixed sizes and may not automatically respond to changes in window size or content.
Integration via Webcomponents
The best at the end. Oops, slipped a shot of scoring in there...sorry.
Ok, what are WebComponents?
This technology is basically a set of web APIs that allow developers to create custom, reusable elements that can be used on a website or application.
WebComponents were first introduced by Google in 2011, but it took a while for them to be fully supported by browsers. In the meantime, frontenders have worked diligently to bring WebComponents to older browsers with polyfills and other hacks.
In the meantime, WebComponents have become an established technology and are increasingly used in many modern applications.
With WebComponents, you can create custom HTML elements that can be used in any JavaScript-based application. These elements can have their own CSS and JavaScript logic, which makes them a very flexible solution.
Overall, WebComponents provide a now W3C-standardized way to create reusable UI elements that can be used in different projects. And all without a heavy framework (with its dependency tentacles) in tow.
Advantages
WebComponents offer a lot of advantages for microfrontends. For one, they allow for good encapsulation of logic, structure and styling thanks to the use of Shadow DOM. This prevents unwanted interference between different MFs and provides better maintainability and modularity.
On the other hand, Web Components are reusable custom elements that can be used in different applications and projects. This promotes code reuse and reduces development time.
In addition, Web Components are framework-agnostic and can be easily used with various front-end frameworks and libraries, such as React, Angular, or Vue.
Another major advantage of Web Components is their standardization by the W3C. This ensures broad support and interoperability.
Disadvantages
Despite what I consider to be enormous advantages, there are also a few disadvantages to using Web Components for microfrontends.
For example, there may still be some problems with browser support, especially with older browsers that do not support the technology or only partially. Those who trudge through the vastness of the WWW on the hump of the old Internetexplorer dinosaur will have to work with polyfills here.
The steep learning curve may also be a factor, as developers may have to spend more time learning and understanding the APIs and concepts of Web Components.
Also, the ecosystem is currently smaller than it is for frameworks like React and co.
Another problem with using Web Components can be the communication and state management between different components. Since Web Components are developed independently and have their own Shadow DOM, communication and data passing between components can be more complicated than with traditional frameworks. Developers must implement appropriate mechanisms for synchronizing state to ensure that changes in one component are reflected in other components that access it.
Integration using special frameworks such as Piral and / or Open Components
Special frameworks like Piral or Open Components, to name just two, can sometimes be helpful in the realization of MF. Please be sure to read the last paragraph here!
These two frameworks are designed to use web components in a microfrontend context and simplify communication and state management with integrated APIs.
Piral not only allows you to isolate components, but also to perform responsive queries between separately developed backends for different front-end components. Piral also has a user-friendly CLI, making it easy to add new components and modify existing ones - all in hot-reloading mode, so without having to restart the entire application.
Open Components (OC) is also capable of simplifying microfrontends with complex communication and state management. Like Piral, OC is designed to isolate components and give them responsiveness in terms of communication. For more info, see: https://opencomponents.github.io/ (last visit: 2023/05/07 - 16:27).
Old hands like me still know all their sows driven through the village by name. A great advantage, if one resembles the other. One of them, at that time the nicest of all when it came to Microfroentend development, was called Mosaic. Hallelujah, the framework was hyped to the skies.
One of my favorite podcasts when it comes to frontend development is "Working Draft". Can only recommend to everyone if he or she is involved with frontendstuff.
One episode was about Mosaic: "Revision 407: Micro Frontends with Project Mosaic" (see, https://workingdraft.de/407/ , last visit: 2023/05/07 - 16:36). Vanessa Otto (co-host of Wording Draft) (see, https://vannsl.io/) was raving about this very framework at the time of recording.
Here is a recent screenshot of the current state of Mosaic (the former superstar):
What does this tell us?
It says to me:
Stay away from such special frameworks. Not only do they bring with them an entourage of dependencies (the Node Modules folder will soon need its own cloud...), no, these "trend frameworks" are like lunchtime apparitions (Witcher players should now have an advantage). One moment there, the next moment gone...(but not without leaving corpses).
Integration using popular SPA frameworks such as React, Angular (NX) and VueJS.
Since the aim here is merely to provide an overview, albeit a comprehensive one, of the possibilities for implementing MF, I will only briefly discuss the "old acquaintances". And only on the three best-known frameworks in Germany:
With React, developers can use the React component feature to create microfrontends. With Angular (NX), the Nx function is available, among others, and with Vue, the Vue component function. In addition, all three frameworks can use routes and Redux to facilitate communication between the different applications and make them less prone to interference (Redux, after all, takes an approach from functional programming here that I really appreciate).
Should one bring such a framework on board for the realization of MF alone?
As a rule, it does not make sense to bring a particular framework on board alone for the realization of MF. Instead, decisions should always be made based on the project and the objective.
In most cases, however, at least one of the aforementioned frameworks is already in use anyway, so the question rarely arises.
Is it sufficient to rely on the capabilities of the framework in terms of MF architecture?
No, in my opinion this is not (always) sufficient.
There are numerous factors to consider before making a decision. First and foremost, the scope and complexity of the MF system needed must be determined. So does the question of whether existing frameworks are to be integrated or whether completely new solutions are to be developed. Furthermore, in addition to the technical aspects, the maintainability and scalability of the microfrontends solution as well as component and scaling techniques such as "microservices" and "serverless computing" must be considered.
Unfortunately, a universal answer cannot be given - every project differs in terms of its prerequisites.
If it should be sufficient, which it can be, then this statement "We don't need more." should have been made on the basis of, for example, an ADR (Architecture Decision Record). And preferably not by one person alone, which brings us to the next point: Regardless of the choice of framework, it is advisable to establish a dedicated front-end management team that specializes in MF architecture. This can bring together the technical and organizational skills of all the teams involved in the project. Regular training can also ensure that everyone gains a comprehensive understanding of microfrontends and their concepts.
Guiding questions from practice for practice
Finally, here are a few guiding questions that have been driving my teams that I have worked on, whether as an architect and / or developer on this topic.
May you draw wisdom from them!
Do I want to integrate UI components from another system at all? If the requirements are very different, might a "separate paths" solution be considered?
Is it possible for separate components to be reunited if they interact strongly with each other and appear together frequently?
Does it make sense to involve UI/UX designers? Talking to UI/UX can help determine if there are routing issues, for example, and user flows can be mapped to determine integration and interaction requirements.
Who is responsible for each component and for the data/UI? Who "owns" it? Are there team dependencies that could cause bottlenecks?
Lookup: where are the endpoints located?
Authentication: does the underlying service bearer require tokens, ETAG or other auth?
Instantiation: what details (props) are needed to invoke the MF?
Events: which incoming events (recieves) can the MF handle, which ones does it send (emigs)?
My sources
Books
YouTube
• Luca Mezzalira (InfoQ) - „Microfrontends Anti-Patterns: Seven Years in the Trenches“ https://www.youtube.com/watch?v=n1XSeiLhBtE&t=366 (last visit: 2023/03/19 – 11:25)
Web (= (blog)article)
• https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout (last visit: 2023/03/19 – 11:38)
• https://martinfowler.com/articles/micro-frontends.html (last visit: 20/03/2023 – 17:44)
• https://www.heise.de/blog/Micro-Frontends-die-Microservices-im-Frontend-5057255.html (last visit: 2023/03/19 – 18:28)
• https://medium.com/@witek1902/ui-in-microservices-world-micro-frontends-pattern-and-web-components-23607a569363 (last visit: 20/03/2023 – 17:43)
• https://samnewman.io/patterns/architectural/bff/ (last visit: 20/03/2023 – 17:46)