The Ultimate Guide to Micro Frontends: Architecture, Patterns, and Implementation

The Monolith That Broke My Trust: How Micro Frontends Became a Necessity

Around 40% of a typical developer's time goes into maintaining existing code. When I was building Trust Revamp, my Shopify app for social proof and reviews, that number felt closer to 80%. We started simple. A single React application, a few pages, a clear goal. The initial launch went well. Customers loved it. We added features: photo reviews, video testimonials, advanced analytics. Each new component, each new integration, meant more code piling into the same repository.

I remember one Friday afternoon in my small office in Dhaka. It was 2024. I needed to push a minor bug fix – a CSS tweak on the review widget. A five-minute job, I thought. I pulled the latest code, ran npm install, then npm run build. The build process choked. It took over 15 minutes. Then it failed. A dependency conflict. A new feature branch from my contractor had introduced a breaking change in a shared utility file. I spent the next two hours untangling package versions, resolving merge conflicts, and trying to understand why a tiny CSS change required me to become a full-time Git archaeologist.

This wasn't an isolated incident. Deployments became terrifying events. A small change in one part of the app could inadvertently break something completely unrelated. Our codebase was a giant, tangled ball of yarn. We couldn't deploy independently. We couldn't scale teams effectively. Two developers working on different features constantly stepped on each other's toes. The cognitive load was immense. My AWS Certified Solutions Architect training screamed for modularity, but the frontend remained stubbornly monolithic. This cost us. It cost us time. It cost us developer sanity. Most importantly, it cost us the agility to ship new features fast, directly impacting our growth. I knew something had to change. The single-page application, once a blessing for its perceived simplicity, had become our biggest bottleneck.

Micro Frontends in 60 seconds: Micro Frontends break a large, monolithic frontend application into smaller, independently deployable web applications. Each micro frontend is owned by a distinct team, can use its own technology stack, and deploys independently. This architecture significantly reduces coupling, improves team autonomy, and allows for faster, more reliable deployments of complex web interfaces. Think of it as applying the microservices principle to your frontend.

What Is Micro Frontends and Why It Matters

Micro Frontends represent a paradigm shift in how we build complex web applications. At its core, it's about decentralizing the frontend development process. Instead of a single, sprawling codebase for your entire user interface, you break it down into smaller, self-contained applications. Each of these smaller applications, or "micro frontends," functions independently.

The concept isn't new. It mirrors the microservices architecture that revolutionized backend development. Just as microservices decompose a monolithic backend into smaller, manageable services, micro frontends decompose a monolithic frontend into smaller, manageable UI components or sections.

Why does this matter? Let's go back to first principles. Software development, especially for SaaS products like Store Warden or Paycheck Mate, is about managing complexity and enabling change. A monolithic frontend, while simple to start, quickly becomes a hindrance as your product grows.

Consider a large e-commerce platform. It has a product listing page, a shopping cart, a checkout flow, user accounts, and an admin dashboard. In a monolithic setup, all these features reside in one giant frontend application. A team working on the checkout flow might inadvertently introduce a bug that affects the product listing page. A technology choice made years ago for the entire application restricts new features from leveraging modern frameworks.

With micro frontends, each of these features – product listing, shopping cart, checkout – could be a separate micro frontend.

• The product listing team could use React.
• The shopping cart team might prefer Vue.
• The checkout team could even experiment with Svelte.

They deploy their parts independently, without impacting the others. This isn't just about tech stack flexibility; it's about operational independence. As an AWS Certified Solutions Architect with 8+ years of experience, I know that independent deployment is critical for high availability and rapid iteration. When I was scaling Flow Recorder, the ability to push a small update without redeploying the entire application would have saved weeks of testing and coordination.

The fundamental reason micro frontends matter is simple: they reduce the blast radius of change. A bug in one micro frontend doesn't bring down the entire application. A slow deployment of one feature doesn't hold up critical bug fixes for another. This allows teams to move faster, own their domain end-to-end, and ultimately deliver more value to users. It's not about making things easier for the sake of it; it's about making your development process resilient and scalable enough to handle the demands of a global audience.

Implementing Micro Frontends: A Practical Framework

You understand why micro frontends matter. Now you need to know how to build them without making the expensive mistakes I did. This isn't theoretical. This is what I follow when I build scalable SaaS products like Flow Recorder or Store Warden.

1. Define Your Boundaries, Not Just Your Code

This is the most crucial step. Most guides jump straight to code. I don't. Before writing a single line, you must define the logical boundaries of your micro frontends. This isn't a technical decision alone. It's an organizational and domain-driven one.

• Mistake I made: I tried to split by UI elements, like "header" and "footer." This was a disaster. These elements often need data from everywhere. They become complex shared dependencies.
• My Fix: I learned to identify autonomous business capabilities. Think of your product as a set of services. For Store Warden, Inventory Management is one. Order Processing is another. Customer Analytics is a third. Each of these becomes a micro frontend. Each owns its UI, its data fetching, and its business logic. This mirrors the principles of domain-driven design, which I believe is essential for any complex system. You can read more about my approach to domain-driven design.

2. Choose Your Integration Strategy

Once you have your boundaries, you need to decide how these independent applications will come together in the user's browser. There are main approaches.

• Module Federation (Webpack 5): This is my preferred method for modern JavaScript frameworks (React, Vue, Svelte). It's built into Webpack 5. It allows different applications to expose and consume modules from each other at runtime. You dynamically load code from other applications. This is powerful. It works well for Flow Recorder, where different parts of the workflow engine are separate React apps.
• Web Components: This is a framework-agnostic approach. Each micro frontend is encapsulated as a custom HTML element. The main shell loads these components. This works when you have a truly polyglot environment or want maximum isolation. I used this for a specific part of Trust Revamp to integrate an older Angular component with a new React one.
• iFrames: Simple, but comes with significant drawbacks. They offer strong isolation. But communication between iFrames is a headache. Routing becomes complex. Shared context is nearly impossible. I tried this once for a quick prototype. I abandoned it within weeks. The UX was clunky.

My recommendation: Start with Module Federation if you're in the modern JS ecosystem. It offers the best balance of flexibility and performance.

3. Establish a Robust, Minimal Shell/Container

This is the "glue" that holds everything together. The shell is a lightweight application. It's responsible for:

• Loading and rendering micro frontends.

• Providing global navigation.

• Handling authentication.

• Managing shared layout.

• The skipped step: Many guides focus on how to build micro frontends. They often understate the importance of the shell. A common mistake is making the shell too smart, too complex. Then it becomes a new monolith. I've seen this happen.

• My Fix: The shell should do only what's necessary to orchestrate. It shouldn't contain business logic. It should be framework-agnostic if possible. It provides the canvas. The micro frontends paint on it. For Flow Recorder, my shell is a lean React app. It loads the WorkflowEditor micro frontend, the Dashboard micro frontend, and the Settings micro frontend. It passes down user authentication tokens. That's it. Keep it minimal. It reduces the "blast radius" on the shell itself.

4. Standardize Communication Protocols

Micro frontends are independent. They still need to talk to each other. You need clear rules for this.

• Custom Events: Browser custom events are a simple, native way for micro frontends to communicate. One micro frontend dispatches an event. Another listens for it. This is decoupled. It's effective for simple interactions.
• Shared State Libraries: For more complex shared data, you can use a lightweight global state management solution. This state is managed by the shell or a dedicated shared library. Micro frontends can subscribe to changes.
• API Gateways: For communication involving backend data, micro frontends should talk to their own backends, or a shared API gateway. Each micro frontend exposes its own API endpoints. This maintains backend independence too.

I tend to lean on custom events for UI interactions. For critical shared data like user profile information, I use a tiny, shared store managed by the shell. It keeps things simple.

5. Implement CI/CD for Independent Deployment

The biggest promise of micro frontends is independent deployment. This only happens with a robust CI/CD pipeline for each micro frontend.

• Each micro frontend: Needs its own Git repository. Its own build process. Its own deployment pipeline.
• My experience: When I was building Paycheck Mate, we had a monolithic frontend. A small bug fix meant redeploying the entire application. The QA cycle was days. After splitting, each feature team owned its deployment. A bug fix for ExpenseTracker deployed in an hour. It didn't touch IncomeDashboard. This is where the real value comes from. As an AWS Certified Solutions Architect, I design pipelines specifically for this. Independent deployment is critical for rapid iteration and high availability. I wrote more about setting up efficient deployment pipelines in my post on CI/CD best practices.

6. Set Up Observability and Monitoring

You cannot fix what you cannot see. With multiple independent applications, centralized observability is non-negotiable.

• Centralized Logging: Aggregate logs from all micro frontends into a single system (e.g., AWS CloudWatch, ELK stack). This helps trace issues across application boundaries.
• Distributed Tracing: Tools like OpenTelemetry or AWS X-Ray allow you to trace user requests as they traverse different micro frontends and their backends. This is essential for debugging performance bottlenecks.
• Monitoring Dashboards: Create dashboards that show the health and performance of each micro frontend individually, and the overall application.

I learned this the hard way. Early on, a bug would surface, and I'd spend hours figuring out which micro frontend was responsible. Centralized logging cut that debug time by 70%.

7. Address Cross-Cutting Concerns Thoughtfully

This is where many micro frontend implementations stumble. Things like design systems, shared utilities, and authentication.

• Shared UI Components/Design System: Don't build a monolithic shared UI library that every micro frontend depends on. That creates a new monolith. Instead, distribute design tokens (colors, fonts, spacing) and atomic components (buttons, inputs) as read-only packages.
  • My Fix: Each micro frontend consumes these design packages. It builds its own specific components. This ensures visual consistency without tight coupling. For my Shopify apps, I have a core design system package. Each app consumes it. They don't share complex logic components.
• Authentication: The shell typically handles initial authentication. It then passes a token (e.g., JWT) to the micro frontends. Each micro frontend validates this token with its own backend.
• Routing: The shell manages the top-level routing. When a micro frontend needs to navigate to a different route within itself, it handles that locally. For cross-micro frontend navigation, it emits an event, and the shell updates the route.

This step is critical. It sounds like good advice to share everything. It's not. I've learned that sharing too much creates dependencies that negate the benefits of micro frontends. You need to be extremely deliberate about what gets shared.

Micro Frontends in Action: My Learnings from Production

I've built over half a dozen SaaS products. Each time, I've learned more about what works and what doesn't. Micro frontends aren't a silver bullet. They're a powerful tool if you use them right. Here are two real-world examples from my projects.

Example 1: Streamlining Store Warden's Complex Dashboards

Setup: Store Warden is my Shopify app for store management and analytics. It has several complex dashboards: inventory, sales, customer insights, and settings. Initially, I built it as a single, monolithic React application. One create-react-app instance for everything.

Challenge: As Store Warden grew, adding new features became a nightmare. A small change in the Inventory dashboard might break the Sales Analytics page. Deployments were slow. Each release required extensive QA across the entire application, often taking 2-3 days. Onboarding new developers was tough. They had to understand the entire sprawling codebase.

What Went Wrong: My first attempt at "splitting" was superficial. I tried to split by page, not by domain. I had InventoryPage.js, SalesPage.js, etc. They were still all in the same Webpack bundle. They still shared a lot of implicitly coupled state. This didn't reduce the blast radius. A bug in one "page" could still easily affect others because they were built and deployed together. It was still a monolith, just with more files.

Action: I refactored Store Warden into domain-specific micro frontends using Webpack's Module Federation. I defined three main micro frontends:

• StoreWardenInventory: Manages all inventory-related UI and logic.
• StoreWardenAnalytics: Handles sales, customer, and product analytics.
• StoreWardenSettings: Manages store settings and user preferences.

Each micro frontend became its own independent React application, with its own build process and deployment pipeline. The main Store Warden app acted as the shell, dynamically loading these micro frontends.

Result: The impact was immediate and significant.

• Deployment Speed: Deployment cycles for new features or bug fixes reduced from 2-3 days of full regression QA to just hours for a specific micro frontend.
• Team Autonomy: I could assign different developers to work on specific dashboards without fear of them breaking other parts of the application.
• Reduced QA Time: I saw a 40% reduction in overall QA time per feature. A bug in StoreWardenInventory no longer affected StoreWardenAnalytics.
• Performance: Users only loaded the JavaScript for the specific dashboard they were viewing, improving initial load times for unused sections.

Example 2: Scaling Flow Recorder's AI Workflow Editor

Setup: Flow Recorder is my internal tool for AI workflow automation. It's complex. It has a drag-and-drop workflow editor, a dashboard for monitoring runs, and an admin panel for user and model management. Different user roles (editor, viewer, admin) interact with distinct parts of the UI.

Challenge: The initial architecture was a single, large Node.js (Express) backend with a monolithic React frontend. The workflow editor itself was a heavy component. Updates to the admin panel often introduced regressions in the editor, or vice-versa. The performance for different roles was inconsistent, as everyone loaded the entire application.

What Went Wrong: I initially tried to use iFrames to isolate the different role-based views. It seemed like a quick way to achieve separation. The isolation was strong. However, it made shared navigation incredibly difficult. Passing data between the main application and the iFramed micro frontends was clunky. The user experience felt disjointed. Authentication context also became a nightmare to maintain across iFrames. It felt like I was building multiple mini-applications that hated talking to each other.

Action: I migrated Flow Recorder to a Web Components architecture for the frontend.

• The WorkflowEditor was encapsulated as a <flow-editor> Web Component.
• The Dashboard became <flow-dashboard>.
• The AdminPanel became <flow-admin>.

The main shell application (a lightweight React app) loaded these Web Components. I established a simple custom event bus for cross-component communication. This allowed for framework independence if I chose to introduce, say, a Vue component later.

Result: This architectural shift delivered several key benefits:

• True UI Isolation: Each component was truly independent. The editor team could iterate rapidly without affecting the admin panel.
• Improved Performance: Specific user roles only loaded the Web Components relevant to their view. An editor didn't load the admin panel's heavy JavaScript. This improved initial load performance by 15% for the editor view.
• Enhanced Maintainability: New developers could focus on understanding just one Web Component. They didn't need to grasp the entire application's complexity.
• Technology Flexibility: While I stuck with React, the Web Components approach meant I could have introduced a different framework for a new feature without rewriting the entire application.

These examples show that micro frontends are not just for huge enterprises. They solve real problems for solo founders and small teams building complex SaaS products. They reduce stress and increase development velocity.

Avoiding the Pitfalls: My Costly Micro Frontend Mistakes

I've learned from my failures. Micro frontends promise a lot, but they introduce new complexities. Here are common mistakes I've made, and how to fix them.

Over-Splitting Your Application

Mistake: You get excited about the idea. You start splitting everything. The header, the footer, a small button. Each becomes its own micro frontend. This creates an explosion of repositories, build pipelines, and deployment targets. The overhead outweighs the benefits. I did this on an early project, trying to achieve "maximum modularity." It just created maximum chaos.

Fix: Start with larger, domain-driven boundaries. Think "Inventory Management" or "User Profile," not "Search Bar." Split further only when you experience clear pain points like slow deployments, conflicting dependencies, or team blockers.

Ignoring Shared State and Communication

Mistake: Each micro frontend becomes an island. They don't know how to talk to each other. You need to pass user data, routing information, or trigger events across them. Without a plan, you end up with ad-hoc, brittle communication mechanisms. I had micro frontends that needed to update a global cart count. Without a clear protocol, it became a mess of direct DOM manipulation and localStorage hacks.

Fix: Design explicit communication channels from the start. Use browser custom events for simple UI interactions. Implement a lightweight global state management solution (e.g., a simple Pub/Sub pattern or a tiny Redux store) for truly shared data. The shell can facilitate this.

The "Monolithic Design System" Trap

Mistake: You want consistent UI. So you create a single, massive shared UI component library. Every micro frontend depends on it. This library then becomes a new monolith. A change in one component breaks every micro frontend. You're back to square one with coordinated deployments. This sounds like good advice – "share common UI." It's not when taken to an extreme. I experienced this with a client's project. A single Button component update required re-testing 10 different micro frontends.

Fix: Distribute design tokens (colors, typography, spacing) and atomic, read-only components (buttons, inputs) as separate, stable packages. Each micro frontend consumes these. But avoid sharing complex, logic-heavy components. If a micro frontend needs a specialized "Product Card," it builds its own. Duplication of simple UI logic is often better than tight coupling.

Inconsistent Tooling and Build Processes

Mistake: Each team or developer picks their favorite build tool, linter, and testing framework for their micro frontend. One uses Webpack, another Vite. One uses Jest, another Vitest. This leads to a fragmented developer experience, increased maintenance overhead, and difficulty sharing knowledge. When I was scaling a WordPress platform with multiple frontend components, this was a constant battle.

Fix: Establish a starter template for new micro frontends. Standardize core tools: a single bundler (Webpack or Vite), a single linter (ESLint), and a single testing framework. Allow flexibility for framework choice, but enforce consistency for the underlying build and dev environment. A monorepo tool like Nx can help manage these configurations across multiple projects.

Neglecting Cross-Functional Concerns

Mistake: You focus solely on splitting the UI. You forget about security, performance, accessibility, and SEO. Each micro frontend might have its own vulnerabilities, performance bottlenecks, or accessibility issues. Without a centralized strategy, these become hard to track and fix.

Fix: Integrate security scans, performance audits, and accessibility checks into each micro frontend's CI/CD pipeline. The shell should handle common SEO concerns (meta tags, sitemaps). Treat these as non-negotiable requirements for every micro frontend.

Essential Tools and Resources for Micro Frontend Development

Building micro frontends requires the right toolkit. Here are the tools and resources I rely on, including some underrated gems and a commonly overrated solution.

Category	Tool/Resource	Why I use it / My experience
Orchestration	Webpack Module Federation	My go-to for modern JavaScript frameworks (React, Vue, Svelte). It allows dynamic loading and sharing of modules at runtime. It's powerful, works seamlessly with existing Webpack setups, and forms the backbone of many of my micro frontend architectures, including parts of Store Warden.
	Luigi (SAP)	A comprehensive enterprise-grade micro frontend framework. It's robust for large organizations. I've explored it for client work. It provides a shell and routing. It can add complexity if your needs are simpler.
Build Tools	Vite	Incredibly fast build times and a superb developer experience. While Module Federation is Webpack-specific, Vite is excellent for building individual micro frontends that can then be integrated via Web Components or other methods. I use Vite for new micro frontend projects where applicable.
Monorepo Mgmt	Nx (Underrated)	This is a monorepo tool that helps manage multiple micro frontends, shared libraries, and build configurations in a single repository. It's not just for large teams. It provides workspace generators and executors. It makes managing shared libraries and running commands across projects much easier. I used it for a client's large-scale financial platform, and it drastically simplified dependency management.
Integration	Custom Web Components	A framework-agnostic solution. It uses native browser APIs to create reusable components. Great for integrating micro frontends built with different frameworks. This is how I handled parts of Flow Recorder, ensuring a clean separation.
Overrated	Single-SPA	It's a robust framework with a clear lifecycle management approach. However, for many projects, especially smaller or mid-sized ones, its overhead and specific plugin ecosystem can be more than you need. Module Federation often provides a simpler path with modern bundlers like Webpack 5. Single-SPA adds another layer of abstraction that might not be necessary.
Resources	martinfowler.com/articles/micro-frontends.html	The foundational article by ThoughtWorks. It introduced the concept. It's still highly relevant.
	You Don't Know JS Yet (Kyle Simpson)	A deep understanding of JavaScript fundamentals is crucial for building robust micro frontends, regardless of your chosen framework. This book series is essential. You can find it on GitHub.

The Bottom Line: When Micro Frontends Deliver Real Value

Micro frontends are not a universal solution. They introduce complexity. But when applied correctly, they unlock significant benefits for scaling development and operations. I've seen it firsthand, from my small SaaS apps in Dhaka to large enterprise clients.

Pros of Micro Frontends	Cons of Micro Frontends
Independent Deployment: Push updates to one part without affecting the whole.	Increased Operational Complexity: More repositories, more pipelines, more monitoring.
Technology Stack Flexibility: Teams pick the best tool for their problem (React, Vue, Svelte).	Requires Strong Governance: Without standards, you get chaos.
Reduced Blast Radius of Change: A bug in one micro frontend doesn't bring down the entire application.	Potential for Inconsistent UX: Without a solid design system, UI can fragment.
Scalable Team Structures: Smaller, autonomous teams own specific domains.	Bundle Size Overhead: Can lead to larger total JavaScript if not optimized.
**

From Knowing to Doing: Where Most Teams Get Stuck

You now understand Micro Frontends, why they matter, and how to approach their implementation. You've seen the common pitfalls I've stumbled into building Shopify apps and scaling WordPress platforms. But knowing isn't enough — execution is where most teams fail. I learned this the hard way on a project where we tried to retrofit Micro Frontends onto an existing monolith. The theory was sound. The practical application, without proper automation, was a nightmare.

The manual way works for a week, maybe a month. Then it's slow. It's error-prone. It doesn't scale. When I was architecting CI/CD pipelines as an AWS Certified Solutions Architect, I realized the true cost of Micro Frontends isn't the initial setup. It's the ongoing operational overhead if you don't automate deployments, testing, and dependency management from day one. You just swap one monolithic problem for a distributed set of problems if your tooling isn't robust. That's a mistake I won't repeat. We spent months untangling build issues that proper automation would have prevented, costing us significant development time and market opportunities for Flow Recorder.

Want More Lessons Like This?

I’ve spent 8+ years building, breaking, and rebuilding software, often making expensive mistakes so you don't have to. I don't sugarcoat failures; I share what actually happened, what it cost, and what I'd do differently.

Subscribe to the Newsletter - join other developers building products.

Frequently Asked Questions

What's the biggest hidden cost of Micro Frontends?

The biggest hidden cost is operational complexity, specifically around continuous integration and deployment. Without a mature CI/CD pipeline, independent deployments become a bottleneck. I've seen teams in Dhaka struggle for months trying to coordinate releases manually. It's not just about splitting code; it's about splitting teams and their deployment cycles. You need robust monitoring and logging across services, which adds overhead. On a project like Store Warden, this meant investing heavily in Docker and AWS infrastructure to manage the distributed nature effectively.

Are Micro Frontends suitable for small teams or startups?

It depends heavily on your team's size, experience, and product roadmap. For a small team with a single product, the overhead of Micro Frontends often outweighs the benefits. You'll spend more time managing infrastructure and deployment pipelines than building features. I generally advise startups to stick with a well-structured monolith until scaling issues (team size, independent feature development) become a real blocker. The complexity of managing multiple repositories, build systems, and deployment artifacts isn't trivial for a lean team.

How long does a typical Micro Frontends migration take for an existing app?

This takes time, often months, sometimes over a year, depending on the monolith's size and complexity. My experience migrating components of Trust Revamp showed it's not a "weekend project." You start by identifying a small, isolated section to extract first. This could be a new feature or a self-contained module. The process involves careful planning, setting up new build systems, establishing communication protocols, and updating CI/CD. Expect significant refactoring. Focus on incremental changes, not a big-bang rewrite.

What's the absolute minimum I need to start with Micro Frontends?

You need a clear understanding of your application's boundaries and a robust build system. Start by defining a single, small, isolated component that can be developed and deployed independently. I often recommend using a module federation tool like Webpack 5. You also need a host application to orchestrate these micro frontends. Don't over-engineer; pick one component, build it, and integrate it. This practical approach helps you learn the workflow before committing to a larger architecture shift.

Does Micro Frontends complicate SEO?

Yes, it can, but it's manageable. Client-side rendering (CSR) micro frontends often make it harder for search engine crawlers to index content properly. I learned this when optimizing Paycheck Mate. The solution involves server-side rendering (SSR) or static site generation (SSG) for your micro frontends, or ensuring your host application pre-renders critical content. You must implement consistent metadata management across all micro frontends. This adds a layer of complexity to your deployment strategy, but it's a solved problem with modern frameworks. For critical public-facing pages, always prioritize SSR.

When should I *not* use Micro Frontends?

You should not use Micro Frontends when your team is small, your product is simple, or you don't anticipate significant growth in team size or application complexity. If you're building a simple marketing site or a single-page application that doesn't require independent teams deploying different parts, the architectural overhead isn't worth it. I made this mistake trying to over-engineer a small internal tool. The benefits of Micro Frontends only materialize when you have large, distributed teams or distinct product areas that truly benefit from autonomous development and deployment cycles.

The Bottom Line

You now understand how to move from a tangled monolith to a nimble, modular frontend. The single most important thing you can do today is identify one small, isolated component in your current application. Then, start experimenting with building it as a separate, deployable unit. Don't commit to a full migration. Just learn the process.

This small step will change how your team approaches development. You'll see faster deployments, clearer ownership, and a more resilient application structure. If you want to see what else I'm building, you can find all my projects at besofty.com.

---

Ratul Hasan is a developer and product builder. He has shipped Flow Recorder, Store Warden, Trust Revamp, Paycheck Mate, Custom Role Creator, and other tools for developers, merchants, and product teams. All his projects live at besofty.com. Find him at ratulhasan.com. GitHub LinkedIn