Micro Front end done right(github.com)
github.com
Micro Front end done right
https://github.com/frontyjs/fronty
12 comments
It’s seldom that simple in the wild. I just had to build a micro front end. The original React app had some parts that were business critical but written quite poorly and required a very specific and weird build chain. The team collectively wanted to start using typescript and a newer version of React but couldn’t without rebuilding this piece of the code. So we isolated it into a microfront end and now have the ability to rebuild it as capacity allows. It’s obviously not ideal but I consider it a good choice as an interim step in complex deprecation tasks. Isolate THEN deprecate. :-)
This approach is what creates technical debt.
It's a method useful for startups only.
Businesses who have moved on from startup status need to switch to a quality first approach.
Deprecation should only be on the table if your original design was flawed. And then only if you are certain you are fixing that particular design flaw completely. So many times have I seen rewrites due to a poor design just create the same design flaw in the new system as a compromise because changing the database would be too hard.
And even then, I strongly question the need for isolation/deprecation like this. It says a lot about your company and creates a broken windows atmosphere where it's ok to push shit because it will eventually be replaced anyway.
"Wanting typescript" is a shitty excuse for putting a business critical system up for adoption.
Literally nobody will want to deal with it within a year. After that, your business critical function, likely one that makes money, is no longer maintained and impossible to change.
Enjoy your growth stagnation.
It's a method useful for startups only.
Businesses who have moved on from startup status need to switch to a quality first approach.
Deprecation should only be on the table if your original design was flawed. And then only if you are certain you are fixing that particular design flaw completely. So many times have I seen rewrites due to a poor design just create the same design flaw in the new system as a compromise because changing the database would be too hard.
And even then, I strongly question the need for isolation/deprecation like this. It says a lot about your company and creates a broken windows atmosphere where it's ok to push shit because it will eventually be replaced anyway.
"Wanting typescript" is a shitty excuse for putting a business critical system up for adoption.
Literally nobody will want to deal with it within a year. After that, your business critical function, likely one that makes money, is no longer maintained and impossible to change.
Enjoy your growth stagnation.
You're reading too much (and filling in the blanks with your assumptions and imagination) from a honest and objective comment from a fellow regarding his personal experience. I'm glad he shared his experience with us, but your post only adds noise to an otherwise interesting discussion.
there are several good reasons to isolate and deprecate
1) web technologies change frequently, junk is accumulated over time if new tooling and updated dependencies aren't adopted- this is more effective in deprecation 2) iteration speed is faster
ultimately code that makes up infrastructure or the foundation of micro*s should be quality first (e.g. auth, kubernetes, microfrontend compositor) but other things should focus on shipping and iteration.
1) web technologies change frequently, junk is accumulated over time if new tooling and updated dependencies aren't adopted- this is more effective in deprecation 2) iteration speed is faster
ultimately code that makes up infrastructure or the foundation of micro*s should be quality first (e.g. auth, kubernetes, microfrontend compositor) but other things should focus on shipping and iteration.
Why don't you ask a couple follow up questions about the situation before you slide into the comments and deliver judgement on a something you know nothing about?
> It's a method useful for startups only.
this is a start up. So yes it's useful.
> Deprecation should only be on the table if your original design was flawed.
It was.
> It says a lot about your company and creates a broken windows atmosphere
It says a lot about what kind of person you are to come at me with a statement like this. The entire reason this approach is being done is to deal with broken windows genius.
> "Wanting typescript" is a shitty excuse for putting a business critical system up for adoption
TS is one of many changes we are adding to deal with the "broken windows" you so snidely commented right before delivering this one. Isolating the part that makes this shift impossible without a lengthy and expensive re-write is absolute the right approach as we can continue delivering features, address tech debt, and leverage this critical piece of software until we can migrate it to the new infrastructure.
> Enjoy your growth stagnation.
Enjoy being a smug asshole.
> It's a method useful for startups only.
this is a start up. So yes it's useful.
> Deprecation should only be on the table if your original design was flawed.
It was.
> It says a lot about your company and creates a broken windows atmosphere
It says a lot about what kind of person you are to come at me with a statement like this. The entire reason this approach is being done is to deal with broken windows genius.
> "Wanting typescript" is a shitty excuse for putting a business critical system up for adoption
TS is one of many changes we are adding to deal with the "broken windows" you so snidely commented right before delivering this one. Isolating the part that makes this shift impossible without a lengthy and expensive re-write is absolute the right approach as we can continue delivering features, address tech debt, and leverage this critical piece of software until we can migrate it to the new infrastructure.
> Enjoy your growth stagnation.
Enjoy being a smug asshole.
Failure to standardise is a sign of a disfunctioning organisation - effectively the embodiment of Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law)
Have worked in organisations where they would rather build something from the ground up every 1-2 years because the organisation has shifted so heavily on what it wants to do/achieve with the same product, and engineering wasn't given the time to properly architect the solution to be adaptable. But the business would insist on having X feature from before and often the easiest way to achieve that was to build micro front ends.
The solution to that wasn't "building them right", it was making them as bad and horrible as possible to point out that the business, their culture and organisation was the problem, not the technology. And when that didn't work, resigning.
Have worked in organisations where they would rather build something from the ground up every 1-2 years because the organisation has shifted so heavily on what it wants to do/achieve with the same product, and engineering wasn't given the time to properly architect the solution to be adaptable. But the business would insist on having X feature from before and often the easiest way to achieve that was to build micro front ends.
The solution to that wasn't "building them right", it was making them as bad and horrible as possible to point out that the business, their culture and organisation was the problem, not the technology. And when that didn't work, resigning.
I fully agree, that's why we created "Piral", which is microfrontend solution that advocates using a single UI library (React). Of course, it also allows running multiple frameworks (such as Angular or Vue), but they are opt-in and by default people should just use a single one.
People sometimes mix up microfrontend with "running multiple frameworks". Its not the same. Actually, the main difference between microfrontends and microservices is that microfrontends should be written with an application shell and many (development) boundaries in place - otherwise the UX will be terrible and hard to get consistent.
Disclaimer: I am one of the people behind Piral (https://piral.io) which is a microfrontend solution based on React.
Disclaimer: I am one of the people behind Piral (https://piral.io) which is a microfrontend solution based on React.
How do you deal with a consistent look and feel in a product with different frameworks? What about code reuse?
Personally, I don't understand what kind of business or product team would fail to standardize on a single application framework. There are so many benefits to having shared solutions to UI and application behavior.
If you set a minimum bar for "we all use React" or "we all use Vue" then you can achieve much nicer integrations between products owned by different teams.