Microfrontends and Parcels: Building Scalable Frontend Architectures

As modern web applications grow in complexity, traditional monolithic frontend architectures often become bottlenecks for development teams. Microfrontends offer a solution by breaking down large applications into smaller, independent pieces that can be developed and deployed separately. In this article, we'll explore how single-spa parcels with React components provide a powerful way to implement microfrontends.

When Should You Use Microfrontends?

While microfrontends offer powerful architectural benefits, they're not always the right choice for every project. Understanding when to adopt this pattern is crucial for making the right technical decisions for your team.

For Smaller Teams: When you have a smaller team working on a frontend application, a traditional monolithic architecture often works perfectly fine. The overhead of setting up and maintaining a microfrontend architecture might outweigh its benefits. A single codebase is simpler to manage, easier to refactor, and requires less infrastructure complexity.

For Larger Teams: As your organization grows and multiple teams need to contribute to the same frontend application, things become more challenging. A single frontend monolith can quickly become a bottleneck where:

• Multiple teams compete for the same codebase, leading to merge conflicts and slower development
• Changes require coordination across teams, reducing autonomy
• Deployments become risky as they affect everyone's work
• Different teams may prefer different frameworks or technology stacks but are locked into one choice

This is where microfrontends shine. It makes sense to split different parts of your web application into independent applications, each with its own:

• Separate build process: Each team can build and optimize their application independently
• Independent domain: Teams can use their own technology stack, libraries, and tools
• Autonomous deployment: Release cycles become independent - one team's release doesn't block another's
• Clear ownership: Each microfrontend has a dedicated team responsible for its development and maintenance

The microfrontend architecture uses a shell application (or container) that orchestrates these independent applications and puts them together into a cohesive user experience. This shell handles routing, communication between microfrontends, and shared resources, while each team maintains full autonomy over their part of the application.

The key benefit? Teams can deploy and release independently, dramatically increasing development velocity and reducing coordination overhead. A bug fix in one microfrontend doesn't require redeploying the entire application, and new features can be rolled out progressively without affecting other teams.

Now that we understand when microfrontends make sense, let's explore how to implement them effectively. Single-spa is one of the most popular frameworks for building microfrontend architectures, and parcels are its core building block for creating reusable, framework-agnostic components that can be shared across your application ecosystem.

Understanding Single-spa Parcels

Parcels are single-spa's way of creating framework-agnostic components that can be mounted anywhere in your application. They are self-contained units with their own lifecycle that can be shared across different parts of your application. When combined with React functional components, parcels become even more powerful and easier to manage.

The power of parcels becomes evident when building complex applications with multiple teams. For example, imagine you're building an e-commerce platform where:

• Team A owns the shopping cart parcel (React-based)
• Team B owns the product recommendations parcel (Vue-based)
• Team C owns the user authentication parcel (React-based)

All three parcels can coexist in the same application shell, communicate through a shared event bus, and be deployed independently. The shopping cart can be updated without touching the recommendations system, and authentication changes don't require rebuilding the entire application.

Throughout this article, we'll build practical examples using React functional components, demonstrating how to create parcels, wrap them for easy consumption, and integrate them into a cohesive application. By the end, you'll have a complete understanding of how to architect and implement a production-ready microfrontend system.

Learn more about single-spa at https://single-spa.js.org/

1. Creating a Basic Parcel Component

A parcel in single-spa is a framework-agnostic component with three lifecycle methods: mount, unmount, and optionally update. Think of it as a self-contained micro-application that can be dynamically loaded and rendered anywhere in your application.

Understanding the Lifecycle Methods:

• mount(props): Called when the parcel needs to be rendered. Receives props including domElement (where to render) and any custom props. Returns a Promise that resolves when mounting is complete.

• unmount(props): Called when the parcel needs to be removed from the DOM. Responsible for cleanup, including removing event listeners and unmounting React components. Returns a Promise.

• update(props): (Optional) Called when props change while the parcel is already mounted. Allows for efficient re-rendering without full unmount/remount cycles. Returns a Promise.

In this example, we'll create a user profile parcel. The parcel configuration defines how the component should be mounted (rendered to the DOM), unmounted (cleaned up), and updated (when props change). This gives you complete control over the component's lifecycle while maintaining framework independence.

Note how we store the React root reference on the domElement itself. This pattern ensures we can properly unmount the React application later and update it when props change. The key advantage is that this parcel can be used in any part of your application - or even in different applications entirely - as long as they're running within the single-spa ecosystem.

1import React from "react"
2import ReactDOM from "react-dom/client"
3
4const UserProfile = ({ user, onUserUpdate }) => (
5  <div className="user-profile">
6    <img src={user.avatar} alt={user.name} />
7    <h3>{user.name}</h3>
8    <p>{user.email}</p>
9    <button onClick={() => onUserUpdate({ ...user, status: "updated" })}>
10      Update Profile
11    </button>
12  </div>
13)
14
15const userProfileParcel = {
16  mount: (props) => {
17    return Promise.resolve().then(() => {
18      const { domElement, ...parcelProps } = props
19      const root = ReactDOM.createRoot(domElement)
20      domElement.__root = root // store for unmount
21      root.render(<UserProfile {...parcelProps} />)
22    })
23  },
24  unmount: (props) => {
25    return Promise.resolve().then(() => {
26      props.domElement.__root?.unmount()
27      delete props.domElement.__root
28    })
29  },
30  update: (props) => {
31    return Promise.resolve().then(() => {
32      const { domElement, ...parcelProps } = props
33      domElement.__root?.render(<UserProfile {...parcelProps} />)
34    })
35  },
36}
37
38export default userProfileParcel

2. Creating a Parcel Wrapper Component

While parcels are framework-agnostic, we need a React-friendly way to work with them. This wrapper component bridges the gap between React's component lifecycle and single-spa's parcel lifecycle, making parcels feel like native React components.

Why Do We Need a Wrapper?

Without this wrapper, you'd need to manually manage parcel mounting and unmounting in each component where you use a parcel. The wrapper abstracts away this complexity and provides:

• Automatic mounting when the component renders
• Automatic unmounting when the component is removed
• Automatic prop updates when data changes
• Proper cleanup to prevent memory leaks

The ReactParcel component uses React hooks to manage the parcel's lifecycle. It leverages useRef to maintain references to the parcel instance and DOM container, ensuring they persist across renders. The first useEffect handles mounting and unmounting, while the second handles prop updates when the parcel's data changes.

This wrapper makes using parcels as simple as rendering any other React component, while still maintaining the full power and flexibility of single-spa parcels. You can reuse this wrapper throughout your application for any parcel you create, regardless of which framework the parcel itself uses.

1import React, { useEffect, useRef } from "react"
2import { mountRootParcel } from "single-spa"
3
4const ReactParcel = ({ config, props }) => {
5  const parcelRef = useRef(null)
6  const containerRef = useRef(null)
7
8  useEffect(() => {
9    if (containerRef.current) {
10      parcelRef.current = mountRootParcel(config, {
11        domElement: containerRef.current,
12        ...props,
13      })
14    }
15
16    return () => {
17      if (parcelRef.current) {
18        parcelRef.current.unmount()
19      }
20    }
21  }, [config])
22
23  useEffect(() => {
24    if (parcelRef.current && parcelRef.current.update) {
25      parcelRef.current.update(props)
26    }
27  }, [props])
28
29  return <div ref={containerRef} />
30}
31
32export default ReactParcel

3. Using Parcels in Your Application

With both the parcel configuration and wrapper component in place, integrating parcels into your application becomes straightforward. This is where the benefits of the microfrontend architecture really shine - you can drop parcels anywhere in your component tree.

In this example, we're building a typical application layout with multiple parcels: a user profile in the sidebar and a notification center in the main content area. Each parcel is loaded independently, demonstrating how different teams can build and maintain separate features that work together seamlessly. Notice how we pass data and callback functions through the props object - parcels behave just like regular React components from the parent's perspective.

The beauty of this approach is that the userProfileParcel and notificationParcel could be maintained by different teams, deployed independently, and even shared across multiple applications, all while integrating seamlessly into your React application.

1import React, { useState } from "react"
2import ReactParcel from "./ReactParcel"
3import userProfileParcel from "./parcels/userProfileParcel"
4import notificationParcel from "./parcels/notificationParcel"
5
6const MainApplication = () => {
7  const [user, setUser] = useState({
8    name: "Sarah Chen",
9    email: "sarah.chen@company.com",
10    avatar: "/avatar.jpg",
11  })
12
13  const [notifications] = useState([
14    { id: 1, message: "New comment on your pull request", type: "info" },
15    {
16      id: 2,
17      message: "Build successful for your project dashboard",
18      type: "success",
19    },
20  ])
21
22  return (
23    <div className="app">
24      <header className="app-header">
25        <h1>Microfrontend Application</h1>
26      </header>
27
28      <div className="app-layout">
29        <aside className="sidebar">
30          <ReactParcel
31            config={userProfileParcel}
32            props={{
33              user,
34              onUserUpdate: setUser,
35            }}
36          />
37        </aside>
38
39        <main className="content">
40          <ReactParcel
41            config={notificationParcel}
42            props={{
43              notifications,
44              userId: user.name,
45            }}
46          />
47        </main>
48      </div>
49    </div>
50  )
51}
52
53export default MainApplication

With these three components in place - the parcel configuration, the React wrapper, and the application integration - you have a complete microfrontend setup. As demonstrated in the example above, multiple parcels can coexist in the same application, each independently developed and maintained. The user profile and notification center parcels could be built by different teams, using different release cycles, yet they integrate seamlessly into the main application.

The pattern is repeatable for as many parcels as you need, allowing you to scale your application architecture horizontally by adding new independent features without increasing complexity. This approach enables teams to work autonomously on different features, deploy them separately, and compose them together into a cohesive user experience. The result is a more maintainable, scalable architecture that grows naturally with your organization.

---

Key Considerations and Challenges

While microfrontends with parcels offer tremendous benefits, there are important considerations to keep in mind:

Performance Optimization

• Lazy loading: Load parcels on-demand to reduce initial bundle size and improve page load times
• Shared dependencies: Use module federation or import maps to avoid duplicating common libraries like React across parcels
• Code splitting: Split large parcels into smaller chunks that can be loaded progressively
• Caching strategies: Implement proper versioning and caching for parcel assets to maximize browser cache hits

Communication Between Parcels Parcels often need to communicate with each other. Common patterns include:

• Props and callbacks: Pass data down and callbacks up through the parent application
• Event bus: Use a custom event system for loose coupling between parcels
• Shared state management: Implement a shared store (Redux, Zustand) that parcels can subscribe to
• Custom events: Use browser's native CustomEvent API for cross-parcel communication

Error Handling Robust error handling is critical in a microfrontend architecture:

• Wrap parcel mounting in try-catch blocks to prevent one parcel's failure from breaking the entire app
• Implement error boundaries around parcels to gracefully handle runtime errors
• Add fallback UI for when a parcel fails to load or mount
• Monitor and log parcel-specific errors for better debugging

Conclusion

Microfrontends with single-spa parcels offer a powerful solution for scaling frontend architectures in growing organizations. By leveraging parcels with React functional components, you can build sophisticated applications that balance team autonomy with a unified user experience.

Key Takeaways:

1. Know when to adopt: Microfrontends are ideal for larger teams working on complex applications, but may be overkill for smaller projects
2. Leverage parcels: Single-spa parcels provide framework-agnostic, self-contained components that can be mounted anywhere
3. Prioritize independence: Each parcel should own its build, deployment, and lifecycle while integrating seamlessly with the shell
4. Plan for scale: Consider performance, communication patterns, error handling, and versioning from the start

---

Ready to begin? Extract one focused piece of functionality into a parcel today and experience firsthand how microfrontends can transform your development workflow and team collaboration!