“You can always be a little bit better” — Drew Brees

Component distribution is hard, especially in a global company. PayPal alone has thousands of components across its network. These components have many versions in production.

To help solve this issue as well as other concerns around UI development, we created Component Explorer. Component Explorer is a UI development gateway that allows our developers to test, share, and consume UI components across our ecosystem. You can read more about it in a previous blog post here: https://medium.com/paypal-engineering/reusing-ui-components-at-enterprise-level-a7df1ea1f8dd

But, as my favorite NFL quarterback Drew Brees states, you can always be a little bit better. We have been striving to make the UI development process better. Some of the problems we have run into are the result of centralized package repositories such as npm.

Centralized Distribution: Not a Perfect Solution

Now, I see the crowd gathering pitchforks and torches, but hear me out. I love npm for its many features and its immense development community. However, npm’s centralized architecture has its drawbacks when it comes to UI development.

Development Velocity and You

First of all, development velocity is one of the key measures of a company’s success and movement forward. Rigid versioning hinders this. With rigid versioning, UI development is held hostage to the cycle of deploy, install, and redeploy that npm package usage requires, causing development delays. When one UI component’s release does not coincide with a consuming application’s release cycle, you can lose up to an entire sprint’s time waiting for the next release cycle to adopt the new version.

Consistency is Key

Along with this release cycle delay, versioning can cause many versions of a UI component to be in use, hindering the consistency of a product’s UI. This UI/UX consistency is arguably one of the most important targets of a company’s UI developers.

So how we do address these issues? We have to completely rethink and redesign how we share components within a tech stack. This is where module federation comes in.

Module Federation: A New Approach

You may have heard of module federation. It’s a brand new feature within webpack, a component bundler used all over the modern web. Module federation is a feature of webpack 5, the newest version of webpack.

Module federation is the ability to publish and consume UI components without using a centralized package repository like npm. This decentralized, app-to-app approach allows you to use and share React components with just a few lines of code sprinkled into your applications.

Webpack’s creator and maintainer, Zach Jackson, wrote a wonderfully in-depth yet easy-to-understand explanation of this technology and I encourage you to read it if you want to know all things module federation: https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669

Benefits of Module Federation

With module federation, we can solve both the release cycle issues as well as the UI consistency issues common with npm usage. Along with this, module federation comes with a host of benefits including

• Easier bug fixes
• Fewer bugs in production
• Better customer experiences
• Unified UI by design
• Faster deploy times
• Consistent versioning

Because of all of these benefits, as well as the ability to address the underlying issues with npm usage, we at PayPal have created an experimental proof-of-concept to test out this technology and its benefits.

How we tried out module federation

First of all, we upgraded our sample app to include module federation. This sample app allows our developers to create component libraries that come with Component Explorer, Storybook, and module federation support out of the box, integrating all new component libraries into this cutting edge by default.

We could have stopped there, as greenfield development support is the easier of the two tasks involved with new technology integration. However, we wanted to show our developers that not only creating new components with this technology was possible and beneficial, but that onboarding existing component libraries to module federation would reap immense benefits for them as well as our customers.

In order to do this, we had to onboard an existing application as a proof-of-concept. We could have picked a simple, non-real component library within our ecosystem to onboard, as this would have been the easier approach. However, we chose to onboard Component Explorer itself to module federation for two reasons.

Real Example, Real Results

First, we wanted a real-world example of the power of this technology. Choosing a small, insignificant component library to onboard would not be a powerful demonstration of this tech. However, Component Explorer is a relatively complex application with a multitude of UI components within its library. It has real impact on the development ecosystem our internal developers are aware of and see regularly.

Module Federation + Component Explorer

Secondly, module federation within our ecosystem is not meant to exist in a vacuum. As a technology, we wanted to couple the benefits of module federation with the existing benefits of Component Explorer in order to more holistically approach and resolve the many issues and concerns surrounding UI development. That is, Component Explorer acts as a gateway for UI development and we wanted Component Explorer now also act as a gateway for federated UI development.

In Conclusion

With these two technologies acting hand-in-hand to help ease the sharing of components within our ecosystem, we hope to create a better developer experience within our company, as well as a better customer experience for our hundreds of millions of loyal PayPal customers worldwide.