Why Micro frontends might fail as microservices

Micro frontends were highly inspired by Microservices. So why not extend the same benefits from microservices to micro frontends, right? Things are a bit easier at the backend because we can actually have proper and real isolation. Meaning process/machine isolation, since we can distribute workloads in different machines. When we are looking into micro frontends is not the same deal. We also need to remember that microservices were highly inspired by SOA and Microservices are a flavor of SOA. Microservices are DEAD and in decline for the Backend, so it's interesting to see it's a major trend for the frontend. At the end of the day the Browser architecture did not change much and in the backend is much easier to have isolations and we have different flavors of isolations like Docker, UniKernels, MicroWorkers, etc... 

In defense of Micro frontends 

First of all, I want to say I believe we need more engineering and more Architecture in the frontend space. We need more content like this and this. At the end of the day, I'm in favor of micro frontends. Meaning we need to get better modularization and better tooling. However, like microservices, I'm afraid we will fail as an industry since often we dont do a good design job and often dont learn from mistakes from the past. Right now it looks like React is the more popular and best way to build web applications. Angular is big on the enterprise side and Vue is growing and we always will have vanilla JS. IMHO the place everybody wants to be right now is using React. However, solutions and frameworks come and go and I'm sure in the near future React will be legacy as much as AngularJS is today(Good luck finding engineers who want to work with AndularJS). 

We all want better isolations and have ways to implement a strangler pattern(check out the post I and II) and be able to migrate new parts of an application into better modularized and more concise parts with newer and better technology. However, there are lots of people who are completely terrified to run different react versions in the same application(and I get why). Using the same frameworks makes things easier and you can have builds and repositories per Domain instead of one single monorepo maybe one monorepo(Buck, Bazel, or whatever) per domain? However, we all need to get rid of that AngularJS legacy right?

In the past, I used Mosaic. In sense of architecture was great. There was a clear separation of concerns(SOC) - however, in the frontend, everything is about tooling and developer experience and that was one of the main issues with Mosaic. Module Federation is exciting and scary at the same time. So long story short micro frontends are evolving and thats great. 

What killed Microservices?

Microservices was always about 2 things. Isolation and smaller granularity. Thats why we have the word "Micro" and thats why SOA never specified any specific granularity and for me this is important. IMHO there is no such thing as needs to be smaller. IMHO it really depends on the domain and somethings make sense to be small and generic like Authentication, Authorization, Encryption, etc.. And others actually are much better to be bigger or more FAT. This idea that everything needs to be micro is really one of the big flaws in microservices and micro frontends are copying that. This is super dangerous. Don't believe me well look Uber and their DOMA story.

Also, keep in mind teams and software suffers from entropy or erosion, and thats the whole monorepo argument right there. But thats, not the worst. IMHO the worst is shared libraries. Shared Libraries are different animals, they are not services, not micro frontends or microservices and if you build them with the same service mentality you end up building a distributed monolith and killing microservices. So what that was todo with micro frontends? Well, module federation, which tends to become the way to go has a way to reuse remotes in different containers(hosts) but at the end of the day, the browser is the same. Easily we cant get abuse here, which could lead to some problems as described for Microservices. 

Fixing the Problem at the Source

Unless we fix the problem on the Browser in order to have better isolation or fix all iframes and web component limitations we might easily create a distributed micro frontend monolith. Plus if we dont pay attention to dependencies and proper design granularity and start having Design Systems written in module federations will not that time we can a button component used everywhere who brings specific Js lib who dont allow us to upgrade other libs and the whole thing fall apart. 

You need to avoid the library Trap at all costs. Library Trap creates Walking Dead libs. So you need to pay attention to that as you will be running on different remotes in the same containers or in common containers.  Tooling is improving, which is great but at the same time will be so easy to do something wrong. So I wonder when we gonna have DDD + Micro Frontends and make sure we think about different domains and proper granularity and lean dependency management. It might take some time for these problems to manifest. But one thing I can tell you for sure. Everybody is talking about the benefits of micro frontends but what about the drawn backs, pain points, and issues? If you dont know the problems it does not mean they dont exist it just means you will learn about them later one :D 

Cheers,
Diego Pacheco



Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all languages in p
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail
read more »