Why micro frontends might not work for you.
Micro frontends are a hot topic currently. Everyone is talking about it. People are curious about how to implement it, what are the pros and cons and so on.
You might be tempted to start implementing your own architecture. You might look at a bunch of resources: Dan Abramov threads, Sean Larkin threads, Luca Mezzalira Blog Posts, examples using server-side include libraries with Node and React, maybe client-side libraries that will help to get the puzzle together.
Did I mention this manifest?
Damn, there is even a Martin Fowler’s blog post about it now.
And I do understand all the fuzz, I also am excited myself! I even made a talk about it using Tailor and Kubernetes in a local meetup in Amsterdam.
You should totally give it a try and see how it feels!
But if you're planning to introduce this in production environments, I would ask you to step back a bit and come with me through some thoughts.
I'm gonna start speaking about Microservices first here so we can quickly refresh our minds on why they actually work so well in many places (and why they also don't).
Microservices are great. Loads of companies adopted it.
They work really well in server-side applications nowadays, mainly because we've been doing this for years, since SOA. The ecosystem is even more healthy now with all the open-source sharing culture and platform that has been built over these last years.
But they're intrinsically different from client-side applications since the dawn of Computing.
Decoupling server applications makes sense because, at the end of it all, they're just servers consuming and producing data at some point in the time.
You want to actually standardize the communication protocols and let the implementations be flexible enough so each team can deal with them in their own best way.
In client-side applications, the picture changes a bit, as the impact of such flexibility might end up being riskier to your product.
Having pieces of your UI floating around with different implementations and being maintained by teams that don't speak often will inevitably add inconsistency in your UI somehow.
If you don't manage dependencies responsibly enough, you might end up with some UX issues, for example.
Your application, in the overall, will turn out to be a way more complex than frontend developers are used to be facing.
It might provide more independence for certain teams, what might make you think that the gain in developer experience will be worth enough. But depending on how you come up with this architecture, you might also affect the developer experience in a bad way.
Which is enough, for example, to motivate developers to not stay in the company because they might believe that all that complexity is just unnecessary and not worth it (or maybe because they don't understand it and neither want to).
Meanwhile, if implemented correctly, with a certain level of strictness, provided with the correct tools, and with a correct culture, you might have what you need to sustain this architecture. It might be worth it.
It doesn't mean it will be cheap or easy, though.
It is for sure a type of architecture that will demand more from a team to contribute and maintain, without any doubt.
In the same way, as microservices are.
One of the main differences is that the microservices ecosystem is way more mature than micro frontends are.
We've been building distributed services for quite a while. You can find talks and articles regarding Service Oriented Architecture dating from 2004.
Microservices are a variant of SOA that started becoming relevant around 2014, almost 10 years later it's very first roots, and it came just on the right moment: with the rise of Cloud Computing. And they simply fit!
We already have a bunch of content, workshops, companies running it in production. They fit nicely with what cloud providers offer us. The path is clearer at this point.
Microfrontends are something quite new. We already had similar stuff 20 years ago, such as PHP includes (sorry for that, is true), but the challenges we face now are way more different:
JS Libraries are quite huge.
Frontend development teams are bigger.
Component interaction is way bigger nowadays than it was back then.
Reactivity and Responsiveness is a must.
Accessibility is a real concern.
A good mobile experience might be critical for you.
Stateful servers are things that must run in controlled environments.
And addressing these issues in such architecture is just not that simple.
Of course, I am not going to stop you.
I want everyone to give it a try, to see more resources about it, to see more examples, implementations and talks about it.
But I also want us to have a first healthy discussion about it before spending a lot of time, effort and money in building something that might not suit our needs, or maybe is just not the right tool for our jobs.
For some, it might be, which is great, but if you're not willing to put such an effort, perhaps you should think twice before introducing it.
—
This article was actually written in Portuguese in a Telegram chat, and people asked for me to write an article out of it. So I hope you enjoyed this and understand what I mean 😄
If you liked this, please make sure to just leave some claps (you can clap more than one-time mate, for real!)
Feel free to ping me on Github or Twitter as well if you want to speak more about it.
And make sure to enjoy your day, cheers! 🥂
