Let's Talk About MicroFrontends

twitter logo github logo ・1 min read

It seems to be all the buzz on JavaScript Twitter:

https://twitter.com/rickhanlonii/status/1139323696953352192

Some people have been talking about full-stack microservices, where you have separate parts of the frontend held together by a stitching layer. For example, one team could work on one component in React, another in Angular, each with their own separate build pipeline.

Despite it being all the buzz today, The idea has been around for at least a year, as seen by this dev.to post:

https://dev.to/onerzafer/understanding-micro-frontends-1ied

So, what do you think? I thought dev.to would spawn some more nuanced and interesting discussion over the Twitterverse.

twitter logo DISCUSS (6)
markdown guide
 

All I can think is about the amount of resources needed to download everything. Requiring people to download multiple frameworks seems concerning to me. On slower or less reliable connections, what is the impact of supporting multiple frameworks and versions of them?

I understand the appeal of them, but I am sceptical that the convenience now, will not lead to bad practices and increased surface area for vulnerabilities down the line. However my knowledge of this technology is limited.

Whats wrong with sticking with one or waiting for web components?

 

Microfrontends don't have to have massive downloads if you're sensible about your technology choices, but you must a very smart real-time bundle builder, which most people won't invest in just to save a few MBs. Besides, as an MFE would most likely be for a web application more than a website, the extra download wait might be understood and accepted by the end users. Performance tuning an MFE is a fairly complex topic on a lot of levels, but in my experience, the initial load is the least of your problems - keeping the browser from dying when rendering real-time data in a complex user interface is a performance dragon that is difficult to slay.

You understand the appeal for general use? I sure don't. I believe they have a niche usage to highly complex deeply integrated user interfaces maintained by organizationally and culturally divergent development teams.

I would say it an architectural style moreso than a technology. Those two tend to get muddled in our industry, unfortunately.

For a sandboxed web browser, you don't tend to increase your surface area, but of course, the most code you have, the more opportunity for exploits, but the volume of code and choice of architecture don't have to have a direct correlation (though there is a correlation).

MFE are a very heavy solution to a very specific problem. When you need one, you need one. When you don't, you don't.

 

When I say that I understand the appeal, I mean that I can see why a multifaceted company would decide to group fragmented tech into one place.

I dont really agree with the principle in general, seems a bit too overkill to me, even React feels like too much complexity for most applications.

I didnt even think about web apps or bundling tbh, I can see why they would influence decisions.

Ah, I understand the context of why you saw the appeal now.

Whether a solution is overkill for a given problem depends on the solution and problem. I have a phobia of snakes, and have promised my wife that should I ever find a snake in the house I would burn it to the ground, which can be argued is overkill for the problem, as I could simply flood the house with nerve toxin or recruit a band of rabid honey badgers.

For people.neilon.software, I built a simple web page. For scorecard.dev, I built a React app. For neilonsoftware.com, I use a hosted Wordpress site. Each choice of technology was based on the original problem I was trying to solve.

Far too often in our industry, people pick a trendy solution and try to apply it to every problem they encounter, which leads to confusion over topics like assessing the value of Microfrontends. A microfrontend is an architecture that is appropriate when it is appropriate, and not appropopriate when it is not appropriate. Whether it is appropriate or not depends on the problem you are solving.

 

I've built a (what is now apparently called) a micro-frontend back in 2015, for a multi-national FinTech with dozens of independent dev teams. I can try to answer specific questions, but I actually don't understand what the main points of confusion are.

 

Can't we just use dynamic/async components and be done with?

Classic DEV Post from Aug 13

How open-source will Tumblr become?

Glenn Stovall profile image
Full-stack engineer. Currently exploring machine learning. I also write on my blog here: https://glennstovall.com/articles-archive/