Over the past few weeks the there has been a ton of discussion around micro-frontends (some negative, some positive).
There was one tweet that r...
For further actions, you may consider blocking this person and/or reporting abuse
I like every new approach in the front-end world.
I'm sure we'll see a job advertisement like that;
We're looking for front-end developers. Must have worked with the micro-frontends for +5 years.
This isn't a "new" concept. You could definitely have multiple years of experience on this.
hahahah
But why do this? I'm not saying I wouldn't want this, but why would I?
If you are a huge company that has to create an app where parts of it are developed by different teams, and different teams that might have different skill sets or preferences.
It's an architectural model that is probably overkill if you're a solo developer or a small team building a regular web app.
If you watch the video @dabit3 linked:
I agree with @rhymes answer, and also check out the video here.
you'll find out it's exactly for apps that have become too big and need to be re-engineered.
Most big companies don't have the luxury to start from scratch.
If you start an app from zero with dozens of developers in different teams, this should be useful as well
I could imagine some special cases like complex realtime-dashboards for stock-traders. Or apps like Spotify, where one team would handle the actual playing of music, and other teams handle playlist curation and social functionality.
Something often not mentioned in discussions: Microfrontends can be split horizontally or vertically.
Horizontally would mean the case described here: Multiple independent apps on one view. I really don't want to see the resulting bundle-size for this approach.
Vertical splitting means you have one app for one view, and separate e.g. by subdomain where login.app.com, news.app.com, editor.app.com each have their own app. DAZN works like this, for example.
This is the key point. With microfrontends you get another dimension for splitting / allocating teams, allowing multiple compositions, e.g., real (independent) fullstack teams.
Thank you, there are some examples I understand
I agree with @rhymes answer, and also check out the video here.
For whatever reason name ticks me off - Single Single Page Application...
MFE architecture is really interesting.
But the main reason I like it, is the possibility to publish parts of an app independently.
The approach showed here didn't get this result, we have to bundle everything together.
I agree. I don't see this example as independent frontends because ate the end of the day, they are all bundled together. If you make a change in the react frontend, you have to rebuild all together. Doesn't make to much sense.
This is probably more a trade-off than anything. It seems like the choice is between a) rebuild everything together which de-duplicates dependencies but you lose the ability to release independently or b) build and release everything separately but risk having duplicate dependencies across all bundles.
I really do wish they had a better name for this pattern. Maybe "Composable apps"? can we make that happen?
The way i see it is like Django apps but for client-side javascript.
Does really name matter ?
It's pattern to solve specific problem
Yes, it does matter. Remember
serverless? Tell me that is not a confusing name.Anyway, "microfrontends" doesn't say anything useful about the problem they are trying to solve. How micro is "micro". And "frontend"? isn't that the whole user interface how can it be micro? The confusion only increases when someone mentions that it can involve multiple frameworks (how can that still be micro?). If we are talking about independent UI pieces, we already have "components" how is this any diferent?
If you hear "composable apps" things change. "App" means that this thing is independent (maybe a whole team build it), "composable" maybe means that is meant to work along side another app or inside of it.
Would thinking about it in conjunction with "microservices" and the problems they solve help?
It does help. It would turn it into a dangerous game, we can't just put "micro" in front of everything and hope people understand.
Replace microfrontend with microservice, and your concern is still valid. Naming is hard:
Anyway, "microservice" doesn't say anything useful about the problem they are trying to solve. How micro is "micro". And "service"? isn't that the whole user system how can it be micro? The confusion only increases when someone mentions that it can involve multiple frameworks (how can that still be micro?). If we are talking about independent api pieces, we already have "request handlers" how is this any diferent?
As someone who's half in Django code and half in front-end code, this is the description I never knew I needed. This really makes sense to me.
This feels like still too much is shared b/t the multiple front-end apps. You could deploy your Vue and React apps as fully standalone (no shared code, configuration, code base, etc.) applications. Then use an upstream load balancer or CDN to route incoming requests to the right origin server based on the URL path pattern. For example all /products/* requests go to the React app and /cart/* requests to the Vue app. The only other consideration is making sure navigation links that cross app boundaries are full page requests rather than client routed links. I assume the AWS Management Console works along these lines, i.e. us-west-2.console.aws.amazon.com/d... is a completely separate app than us-west-2.console.aws.amazon.com/ec2 even though they share a root domain name.
I can think of one great potential use case that I had for micro frontends a few years ago. We had a legacy angular 1 site and google decided to just up and re-write the whole dam framework. As the years wore on it became harder and harder to work with, especially knowing how much better front end libraries and paradigms had gotten. When the time came, we ended up doing a full rebuild ground up to get it off the angular 1 monolith. A pattern like this would have allowed us to gradually move pieces of the site more easily.
Cost wise it may have ended up being roughly the same for the client but in a micro frontends system we probably could have moved a few pages each month over to react rather than do a bit switcheroo after a big multi-month redesign / rebuild. It's a good tool to have in the kit if another situation like this arises.
I can't really understand (as you are mentioning) that people start attacking each other "ad hominem" about a purely technical/professional topic like this. It must be that people are feeling threatened by this development because they think their expertise (React dev, Vue dev, XYZ dev) might become less valuable. Futile of course because change will always be there and is inevitable.
I think this one confuses microfrontends with "run multiple frameworks".
How is this developed independently when its all in the same codebase?
Even if we factor it out (e.g., into libraries); how it this deployed independently if we need to reference it strongly?
Now let's assume all these things are still dealt with. I can run one app (e.g., React) in the main one, but what if my React app wants to use a fragment of another app? I don't see an immediate solution without creating another "Single SPA" host (which then goes full circle to the first question).
Otherwise great article!
My big questions:
I CAN get the same with react. The main concept of component is this like to work on seperate modules by the seperate teams. I didn't see any guide to handle the server requesting in the single-spa so I guess it is not so "needed" even if a big company ca split up there work with react + react-router to achieve this. I guess next-js is much more helpful than this concept.
This is how I just felt about it. The single-spa team did a good job btw with working with such a tech that no one is ready to use it.
I think with this approach you could combine different React versions. Not telling this would be a good idea.
Curious about the bundle size and performance. Also, some lighthouse score maybe 🙂
The micro-frontend approach is just a way to architecture big apps/teams. As long as you are serving the same assets, the browser outcome will be the same.
If you opt for a lazy loading approach: you will have to do a small request for the micro-frontend "runtime" (which decides which bundle to load and use) and an additional one for the actual app (the one the runtime decided to load).
If you opt for an eager loading approach: you will have both apps (with React and Vue) as part of your bundle and you will do only one request
You can come up with whatever loading approach you want to mitigate loading times & bundle size. Think of it as glorified code splitting if you want.
This entire problem is solved by compiling your Vue, React, Angular, etc.. apps to web components. Now you can use your modular mini-app on any site. Agnostic of the framework or even no framework at all.
But a component is not an "app". Micro frontends is about composing multiple 'apps' (which might need to communicate amongst each other) into one frontend. So compiling into web components might be a useful approach but I don't think it's the whole story.
I believe that the only way this is suitable if your team members are bored using React all the time and they want to use something else like Angular or Vue.js. Just throw them some bones to make them happy 🍖 🐩
Hi i have implemented such a poc for my company SAP. Any tips on how to do individual deployments of the micro frontend? Right now it works with local dev env. I implemented this also in iFrame solution. But there's problems with socket connections in safari and SAML single sign on. Any tips would help a lot.
I think some of the confusion for me came from the name, micro-frontend. It makes sense when I learned the name comes from its comparison to a micro-service. It makes sense to look at it as a "Loosely coupled. Independently deployable" frontend
Awesome post! I would, however, add to the list that "mixing technologies together" is not equal to microfrontends. A monolith on the server-side could have also shipped with multiple technologies. The key points are independent development, deployment, and isolation.
While Single SPA may be (e.g., for migration purposes) a good solution I would love to advocate the solution we've been working on for the past few months (actually, its a generalization of an architecture we implemented for several customers in the last ~3 years): we call it Piral.
Piral is an open-source framework for modular frontends, which focuses on developer experience - leveraging totally independent teams. We just presented it for the first team last week at O'Reilly's Software Architecture Conference in Berlin.
Any feedback appreciated!
Love this as a way for large existing apps to be migrated/updated.
Great Post! This is definitely a good solution to problems I have faced.
Overingeniery to dirty software and make people popular.
Danger Post.
Thanks for this great article. I would be interested on how to integrate to an existing application, a new framework. My preference is to add in an existing vue app, svelte.js .
Seems legit.