Streamlining Component Libraries: Moving from a Monolith to a Service-Oriented Architecture at Pearson
Impact
- More effective resource allocation.
- Streamlined development process.
- Enhanced UI consistency across multiple applications.
- Boosted collaboration among the development team.
- Saved significant development time.
- Reduced onboarding time for new microservice frontend developers.
Project Overview
Pearson, a leading learning company, embarked on an ambitious project to scale their existing Credly app (a Ruby on Rails/React monolith) into reusable npm modules. The aim was to separate over 100 custom UI components and utilities into distinct packages to achieve a more scalable service-oriented architecture.
Credly’s application initially faced challenges with its monolithic component system. The disorganization and tight coupling with the main application made it unmanageable by the design system team and non reusable for other applications. Our goal was to create reusable standards around the design system components, but the overlapping contributions to the monolithic system often resulted in UI inconsistencies.
Technology
Spearheading Change
The Decision to Decouple
There were several proposed solutions for this transformation, including a complete rewrite of the library in a separate repository or direct replication of existing components. However, due to limited developer resources and the intricate interdependencies among the components and the application, these solutions were discarded.
After I experienced firsthand the challenges of manually transporting individual components from the existing monolith to the initial component library, I realized that an incremental yet effective approach was needed. The components were tightly coupled with the monolith, which prolonged the decoupling process. It was clear that if we wanted to retain the components, we needed to implement a strategy that would allow for incremental decoupling without blocking new feature development. That’s when I proposed leveraging yarn workspaces, a solution that received approval from the design system team.
The team settled on an approach that harnessed the potential of yarn workspaces to transform substantial parts of our existing libraries into independent npm modules. This approach allowed the code to remain in the existing repository as we progressively decoupled dependencies, preparing the components for external use.
Impact of the Transformation: Collaboration, Time Efficiency, and UI Consistency
This strategic decoupling and deployment of components as npm packages initiated the scaling of Credly’s – and subsequently Pearson’s – system architecture. The result was a consistent user experience across multiple applications. The decoupled code was then transferred from the monolith to a separate repository managed by the design system team.
Implementing yarn workspaces within the existing monolith made it possible for more developers to work on components, multiplying the resources available for component development. With a reduced scope for the new workspace, developers received immediate error feedback when their changes coupled the workspace with the main application, promoting new component standards and accelerating the decoupling effort.
Microservices were able to adopt a consistent UI with the monolith by sharing components, resulting in a uniform user experience. The transformation not only made the component library more manageable but also enhanced collaboration among the development team, saved considerable development time, and reduced onboarding time for new microservice frontend developers. Additionally, any enhancements to the workspace were immediately inherited by the microservice frontends, streamlining the development process.
Challenges and How We Overcame Them
Our journey was not without challenges. The development team held strong opinions about their methods for creating a component library for the design system, sparking many meetings and debates. Additionally, the design system team’s limited resources posed a hindrance to developing the component library.
To counter these issues, we leveraged yarn workspaces to create the package directly within the existing monolith repository. This familiar environment facilitated developer contributions under the new guidance of the design system team, easing the resource constraint. Furthermore, we assured the design system team that the code would eventually be migrated to the design system repository post successful decoupling. This approach not only preserved the existing workflow but also eliminated the need for a complete rebuild.
Retrospective Insights and Future Strategies
This project underscored the importance of efficient resource allocation and the value of leveraging existing systems while making major architectural transformations. It also highlighted the need for effective communication within the team and alignment on the chosen approach.
In retrospect, there are practices that would have made the process smoother from the onset. From the beginning, it would have been beneficial to have built the components directly in the products where they’d be used, as workspaces within a monolith. It allows for a live production environment to test release candidates for npm packages, reducing the need for frequent version bumps in a separate repository.
The most valuable lesson from this project was the importance of keeping reusable component libraries decoupled in workspaces. This experience reinforced the idea that production environments teach us what deserves to be its own external package, guiding incremental improvements to the packages over time. Striving for maximum code lifespan and reducing time wastage means aiming to build components once, whenever possible, while deprecating components that don’t get reused.
This project served as a reminder that the technical decisions we make significantly influence our efficiency, collaboration, and end-user experience. It reiterates the importance of evolving and adapting to challenges in our ongoing quest to deliver high-quality, consistent, and effective digital solutions.
Are you looking for a seasoned professional to join your development team? Does your startup crave the expertise of a technical co-founder? Let’s get in touch!
