The transition from monolithic to Micro Front-end architecture
Development is full of challenges. This could be the legacy project, or the deployment process, or handling dependencies on other team’s components, etc. Challenges like these slow down the developers, which causes the project completion to be delayed. As a result, the software is delivered to the customer late, and the company benefits from it (e.g. getting paid) late. In a way, this puts the company behind in the market. So, every step of the process may be affected by those challenges.
In fact, microarchitectures have emerged to solve such situations. Because breaking large things into pieces makes their management easier. Just as there are no Scrum teams of 50 people, large projects should be divided into appropriately small parts for this reason.
At Insider, we had a monolithic project with front-end and backend together. This meant 100+ people writing code for the same system. That’s what triggered my journey through the land of micro front-ends. Let me tell you which phases I went through.
Selection of Micro Front-end Framework
I’d like to keep it brief. We were torn between Module Federation and Single-spa, and we chose Module Federation because it was more useful for us. Because we used Vue.js and Laravel together, we served the views with the help of laravel-mix.
We also had a webapp in Insider, and its menu helped users navigate to various products. In other words, the page structure of the products and the components on those pages were the same. Module federation outweighed single-spa in terms of reusability for these reasons. Anyway, our transition to single-spa was going to be difficult; translating existing products as a standalone application would have prolonged the process.
Webpack Module Federation Integration
Webpack Module Federation (WMF) is a feature for bundling modules that come with Webpack 5. In other words, it is not a feature specifically made for Micro Front-end, but this is one of its areas of use. There are two sides to WMF. These names may vary: host/remote, shell/remote, core/consumer, etc. I will continue with host/remote in this article.
Host: The monolithic (Vue.js + Laravel) app where we use laravel-mix
const { ModuleFederationPlugin } = require('webpack').container;plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
filename: 'remoteEntry.js',
remotes: {
remoteApp: 'remoteApp@https://remote-app.useinsider.com/remoteEntry.js',
},
exposes: {
'./helpers': './resources/assets/js/helpers.js',
},
shared: {
vue: {
singleton: true,
eager: true,
requiredVersion: require('./package.json').dependencies.vue,
},
},
}),
]Remote: We will connect every app to the host.
config
.plugin('module-federation-plugin')
.use(webpack.container.ModuleFederationPlugin, [{
name: 'remoteApp',
filename: 'remoteEntry.js',
remotes: {
hostApp: `hostApp@https://host-app.useinsider.com/remoteEntry.js`,
},
exposes: {
'./routes': './src/routes/index.js',
},
shared: {
vue: {
singleton: true,
},
},
}]);In this example, you can see that we only share the route file. This was more convenient for our case since the Atomic Design Pattern is used. We exposed the routes and left the routing to the host app.
Now, the host can reach this route file like the below:
import Vue from 'vue';
import Router from 'vue-router';
import otherRoutes from './routes';
import remoteAppRoutes from 'remoteApp/routes';Vue.use(Router);const router = new Router({
mode: 'history',
routes: [...otherRoutes, ...remoteAppRoutes],
});
Hint: If you add your routes dynamically according to your page needs, it will be more efficient for your app’s performance. Because it will just load the remoteEntry.js file from your remote app.
CI/CD Process
Flow:
- The user makes their development and merges the code to the master branch.
- AWS CodePipeline triggers and pulls the code from remoteApp repo.
- It runs the AWS CodeBuild and runs the NPM install and build process, and it also uploads built files to the S3 bucket.
- On the Post Deploy, CodePipeline invalidates the cache for the remoteEntry.js file. It is not needed for other files because Webpack adds hash on the production build.
- After cache invalidation, users are able to see the increment.
Exploring the Upsides and Downsides of Micro Front-end with WMF
Pros
- Hot reload time and file/text searching time will be decreased, too, because the codebase is separated from the main/host app.
- Make deployment whenever you need; you don’t need to wait for the main deployment process.
- Minimum dependency on the other teams/products.
- A defect would have a limited impact.
- Increase in the development team’s ownership.
- Easier to manage individual micro repositories.
- No extra machine cost for the remote app. S3 and Cloudflare handle it well.
Cons
- If you don’t prefer to share common helpers, mixins, components, etc., it might cause code duplication and inconsistency, but it gives more independent development.
- The remote app is dependent on the host app; if the host app goes down, the remote goes down, too.
Conclusion
In conclusion, the transition from a monolithic to a Micro Front-end architecture has marked a significant shift in the development approach at Insider. Recognizing the challenges posed by large-scale projects, the decision to adopt Micro Front-end was driven by the need for improved manageability, flexibility, and accelerated development cycles.
Exploring the upsides and downsides of Micro Front-end with WMF revealed several advantages. Notably, decreased hot reload and file searching times, on-demand deployment capabilities, and increased development team ownership were among the key benefits. The ability to manage micro repositories easily and the cost-efficient handling of remote app resources through S3 and Cloudflare added to the positives.
Thanks for reading my article on Micro Front-end! I have covered some key points to give you a better understanding of the topic. If you enjoyed it, follow our Insider Engineering page for more articles like this. Your support means a lot to us, and we hope you like it. Stay tuned for more!
