Micro frontends: Building In Public From Scratch - Part1 - What are Microfrontends ?

Welcome to the first chapter of our "Build in Public" microfrontends adventure!

In this opening segment, we'll be exploring:

1. What microfrontends are and the core concepts
2. Potential benefits of using microfrontends
3. How microfrontends compare to monolithic architectures

Click here to read introductory post of this series.

There will surely be triumphs, stumbles, and tons of learning along the way! I’m grateful to have you alongside as we unravel the microfrontends architecture step-by-step.

To begin, let’s get grounded in what microfrontends are at a high level...

What microfrontends are and the core concepts
Microfrontends are an architectural style where frontend web applications are broken down into smaller, independently deployable units. Each unit owns a distinct business domain, user workflow, or feature set.

Microfrontends have these key characteristics:

• Owned by small, decentralized teams
• Independently developable, testable, and releasable
• Organized around business domains and features
• Compose together to form the final product

Confused? Let's explain microfrontends using the example of the Indian city of Bangalore.

Bangalore is composed of many distinct neighborhoods like Indiranagar, Koramangala, Jayanagar, etc.

Each neighborhood has its own unique vibe - but they come together to form the metro city of Bangalore.

Similarly, a large microfrontends app is divided into smaller "neighborhood" microfrontends. Each focuses on a specific feature or workflow. The microfrontends integrate together into the final application.

Potential benefits of using microfrontends
Microfrontends excel in situations like:

• Very large, complex frontend apps and teams
• Organization around independent business domains
• Need for technology flexibility across features
• Rapid iteration on specific user workflows

The modular architecture enables smaller teams to move faster on their area of focus.

Comparing to Monoliths
Traditional monolithic frontend architectures contain all of an application's logic in one massive codebase. As the codebase grows, this creates several challenges:

• Coordination overhead - Large teams trip over each other trying to make changes
• Slower release cycles - All changes must be bundled together for deployment
• Spaghetti code - Harder to maintain clean architecture over time
• Scaling difficulties - More developers does not directly speed up delivery
• Technology lock-in - New frameworks hard to adopt across the codebase

Microfrontends aim to solve these issues by distributed ownership across domain-based teams:

• Focused domains - Small teams own specific features end-to-end
• Independent development - Teams can build, test and deploy their domains
• Loose coupling - Teams can choose their own technologies
• Scaling velocity - More teams directly speed up delivery
• Resilience - Changes isolated to their domains

So while a monolith frontend hits bottlenecks as it scales, microfrontends unlock agility by decomposing into distributed domain teams.

However, microfrontends add integration complexity. There are tradeoffs around consistency and shared code as well.

The sweet spot is applications that are large/complex enough to justify the tradeoff. We'll explore guidelines next.

That wraps up a high-level overview explaining the core concepts and motivation behind microfrontends.

I hope this post has provided a solid foundation for what microfrontends are all about and why they may be a useful evolution for certain applications.

Excitingly, this is just the start of our microfrontends journey together.

Next part of this series will be based on following topics :

1. When it makes sense to use microfrontends
2. When not to use microfrontends
3. The pros and cons of a microfrontends approach
4. Setting expectations for incrementally transitioning to microfrontends

I’d love for these posts to reach developers across the world who could benefit from learning about microfrontends.

Please like, follow, and share this post if you found it valuable. The more we can spread the word, the better we can collectively advance the state of web architecture.

I appreciate you coming along for the ride!
Stay tuned!