Enterprise sales-enablement SaaS · 2019
Shipping features into a micro-frontend platform without breaking it
Feature work inside a mature micro-frontend architecture and shared component library, including one of the first production adoptions of React Hooks.
- Enterprise SaaS
- Frontend Architecture
- Design Systems
- React
- Redux
- Redux-Saga
- Micro-frontends
- 8 months
- Engagement
- Independent
- Team deploys
- Library-first
- New UI
Challenge
A global sales-enablement platform had grown to the point where a single front-end codebase was a bottleneck: multiple teams needed to ship independently, and every shared UI change risked breaking someone else’s module. The architecture answer was micro-frontends and a shared component library, which solved the release problem but raised the bar considerably for anyone adding features.
Approach
We worked inside that architecture rather than around it: building new capability in the sales learning module against the shared component library, keeping state predictable with Redux and Redux-Saga, and adopting React Hooks for new work while the surrounding codebase was still class-component based.
Outcome
Features shipped into the learning module without regressions elsewhere in the platform, the shared library absorbed the new UI rather than accumulating one-off components, and the Hooks patterns established here gave the wider codebase a migration path that did not require a rewrite.
Most front-end work is done in codebases where the main risk is your own module. This one was the opposite: a mature enterprise SaaS platform where several teams shipped separately through a micro-frontend architecture, and the shared component library was the contract between all of them. Adding a component carelessly did not just create technical debt, it changed how someone else’s product area looked.
Working with the architecture instead of around it
The tempting shortcut in a setup like this is to build local components inside your own micro-frontend, ship quickly, and leave the shared library alone. It works once, and it degrades the system every time after, which is how design systems quietly die. New UI in the sales learning module went into the shared library, which meant a slower first implementation and a faster fifth one.
State was the other constraint. Redux with Redux-Saga kept side effects explicit and testable, which matters more than usual when your module is loaded alongside others that have their own opinions about the page.
Adopting Hooks before it was routine
React Hooks were new at the time and the surrounding codebase was class-component based. Rather than propose a migration nobody had budget for, we built new features Hooks-first, proving the patterns in production on real functionality, and leaving the wider codebase a path it could take incrementally rather than in one high-risk rewrite.
That is the general principle we bring to established codebases: earn the right to change the architecture by shipping within it first.