Micro Frontends: It's frontend making some mistakes as Backend?

Services are a thing for a long time in the backend. +20 years I would say. Microservices are much newer however they also started the backend. Micro Frontends is a very hot topic in frontend engineering right now. Frontend engineering evolved a lot in the last 5 years. Ui are becoming more and more complex and frontend teams are growing a lot. With complexity and growth, we stumble into classical backend problems such as Teams Organization and Scalability and the need for Isolation as a base for Independence and increase the number of deploys. Frontend technology evolves much faster than backend. With all that comes debit and believe me or not the difficult to find people to work on old tech like AngularJS. 

Micro Frontends Benefits

One benefit from Micro Frontends is Developer Experience. IMHO That's the weakest argument and DX should not be the main reason to do anything in tech. IMHO the real benefits are:

 * Improve Teams Topologies - Reduce the comunication blast radius 

 * Reduce management Overhead (by reducing coordination)

 * Faster Build times by smaller and focused components

 * Technology Diversity (Being able to work with different frameworks)  

The frontend is getting bigger and complex as time pass. We cannot ignore this issue. Technical debt is a big problem at the backend and is becoming a real issue in frontend as frameworks evolve faster and believe me or not is hard to find AngularJS engineers. Micro frontends address a real issue in a sense of scalability and the need to introduce better and newer technology as big companies have issues in refactoring huge code bases. However like any solution, there are drawbacks and issues, so let's take a look into some micro-frontends issues. 

Micro Frontends issues

There are lots of challenges and potential issues with micro frontends such as:

 * Operational Complexity - Deploys are more complex

 * Performance - Might affect the user experience (slower load time)

 * UX/UI Consistency - Need to implement DS for all different frameworks

 * Tooling / Framework support - IMHO it will be fixed but is a huge issue right now

The idea of Micro Frontends is to have independent teams. This can ship things faster, some teams might be faster than others, and in order to do that, you need a different code base and different deployment pipeline. Performance might be a problem since you might load different frameworks and different versions even I would say(you want to avoid this actually). 

Design Systems often are implemented at the component level, so if you have components in one language like Angular and another team want to use React they might need to re-implement the components which might be a big no go for enterprises trying to adopt micro frontends. 

If you can make the Design System implementation more CSS driven rather than framework driven you can minimize this impact, however is very hard to fix completely. A Design system requires the exact same behavior and duplicating to N technologies(Vue, Angular, React, JQueryy/VanillaJS) is expensive since you have fonts, pixels, error, and lots of small details. It's possible but still hard. 

Tooling is a big issue, there is no problem tooling around. There are some solutions with better tooling but often that means by double down into a specific framework. I believe the tooling problem will be fixed eventually.  Zalando has an interesting solution called Mosaic. There is also OC. However, the stand way to go looks like to be around Web Components. It's also possible to do something reasonable with AWS and Simple Infrastructure.

Runtime issues

One big difference from the backend to the frontend and mobile is that in backend we can run the software on different servers so isolation is totally possible. Frontend/mobile has a common issue wihc would be the phone or the browser. It's possible to use shell-like methods like iFrames, Web-Components, or rely on specific frameworks solutions but at the end of the day, the code runs into the same place, which is the browser. It's possible to load different frameworks and solutions but there are performance and complexity penalties. Lots of companies have already frontends monoliths and one common approach people do is to use the monolith as a shell and they have links to the micro frontends apps. 

It's about granularity or Modularization? 

IMHO we don't want to make the components that micro. One hard lesson we learn at the backend is that things too micro also have lots of issues. IMHO what really matters is the ISOLATION and modularization. So you definitely want to have a modular JS application but not necessarily everything needs to be at the micro-level. Micro not always is the right level of abstraction and that is one of the things who killed microservices. 

There is a huge difference in a Brownfield and Greenfield project and a shared old monolith application. IMHO React is the best web framework we have it right now, if you have a new project and create proper components I would say you dont need micro-frontends. However, looking to a more complex enterprise where you have all sorts of solutions I would say you definitely need to have some solution for modularization. 

Having a micro frontend solution imply you to have some solution for the following concerns:

 * SSR (Server Side Rendering) VS CSR (Client Side Rendering)

 * Cache

 * Layout assembling or linking 

 * Routing

 * Testing

It's ideal to have the tooling and good solutions around those concerns. It's possible to do Micro Fronentds without tooling for the concerns I mention however keep in mind it might be less productive, more complex, and much harder to test than good old monolith frontend apps. IMHO Micro frontends might be making the same mistakes as Microservices by focusing on the "micro". What matters is some level of isolation(given the browser reality) and modularization. 

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 language...
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 »