Search for a command to run...
Full Stack Developer 🚀 and Solutions Architect 📟 with a penchant for minimalistic design and optimizations 🕸️. I have hands-on experience in developing web applications using several javascript frameworks, managing & optimizing backend infrastructure including scalability, performance and efficient systems 👨💻.
No comments yet. Be the first to comment.
Almost one and half year ago, I wrote “Building GraphQL API with Nodejs, TypeGraphQL , Typegoose and Troubleshooting common challenges” which covers building a GraphQL API and facing most common challenges that may occur. The major challenge which I ...
I recently started out with this project where I am using Apollo GraphQL with TypeGraphQL , typegoose as mongoose wrapper and Express.js to create an API. I have been searching for different articles on using TypeGraphQL with Typegoose but seems that...
It's been 2 years now I started writing JavaScript applications and JavaScript became my go-to language. So, a year ago I got an internship opportunity at an amazing startup called InVideo. I was told to learn Angular which led me to Typescript. An o...
So In 2018, Ryan Dahl (the creator of Node.js) issued “10 Things I Regret About Node.js” in JSConf , He goes on including several regrets about design he took over Node.js in 2009. Almost half of his talk, he showed us an experimental prototype ...
The term "Micro Frontends" is becoming more popular this days. As there are lot of discussions going on regarding its implementation, Whether we should or shouldn't adopt micro-frontends yet. Let's see what micro-frontends really are.
If you are a backend developer, you might be already familiar with micro-services architecture. But for the front-end developers, it's not that common yet.
Micro-frontends are basically an architectural pattern in which a front-end codebase is decomposed into individual "microapps" consisting of different frameworks / libraries working loosely together, Obviously inspired by backend micro-services.
We could have something like this :
If you notice each microapps can be built with different frameworks or libraries and each microapps can be owned by a single team.
When I was first introduced with micro-frontends honestly it felt a bit off for me and so is to @dan_abramov
But as I started getting familiar with the concept, I realized there are multiple reasons for using micro-frontends. One of the biggest reason would be when migrating from old codebase to a new framework or library.
In early stages of an application it might not be a big problem, But when application grows, the number of teams increases then it becomes a real challenge . When project is massive it becomes difficult to work with multiple people/teams. Unnecessary codebase being available due to which build time is increased. When using same micro-service API it is difficult to make changes when API responses are refactored.
Adopting micro-frontend approach we could solve some of those problems like assigning individual team with core modules. As unnecessary codebase is removed it is easy to deploy and build time also decreases. individual microapps can be developed, tested, and deployed independently, separate modules can be inserted , removed, or replaced without any refactors, different modules of the frontend can be created using different frameworks or libraries. As organization requirements changes we can easily replace old modules with new ones. So we will continuously evolve our codebases.
Some of the big companies are already using it, to name few Spotify, Klarna, Zalando, Upwork, AirBnB, and Facebook.
Well while adopting micro-frontend architecture we have few approaches which can be used :
Using a framework
We can use Single-SPA which lets you combine multiple Frameworks or libraries in a single page.
Using Web Components
Web components can be hosted on different servers with different frameworks or libraries. Chris Kitson has discussed it in depth here : Creating Micro-frontends using Web Components (with support for Angular and React)
Using a separate micro-service for each micro-frontend modules, which can be very beneficial when API changes.
As it comes with many advantages it also have some disadvantages too, while application grows we would be left with tons of codebases to maintain and to maintain the same best practices among all the microapps. It would be very hard to run tests on the the entire codebase locally. While different microapps are hosted on different servers there might be some performance issue which costs user experience. Inter microapps communication can be very difficult and complex to work on.
So basically, micro frontends are all about splitting up big modules into smaller chunks i.e. more manageable modules, and then being explicit about the dependencies between them. According to me Micro-frontend are the future we are heading into but there's still a long way to go. It certainly depends upon the organization requirements and how big the development team is. I hope you have enjoyed this article and got a sense of what micro-frontends really are and different approaches to it.
Thanks for reading, stay awesome! ❤
Feel free to follow me on LinkedIn. Do check my website @ smithgajjar.dev