In 2019, Lyft’s frontend architecture needed a reckoning. We were growing quickly as a company, and new teams were creating new software systems daily. At that point in time, we were generating new frontend services from a service generator template — complete with a copy of our bespoke, zero-config frontend build platform. Having such an easy means of service creation led to an explosion of new services with heterogeneous code built upon our React-based frontend architecture.
At the same time, we were running into headwinds trying to maintain our own frontend platform — an internal set of Webpack configurations, ESLint libraries and framework code — and finding ourselves bogged down troubleshooting cryptic build errors and generally finding our productivity sapped by such support requests. Because codebases began to diverge (as they do in microservice architectures), our developers found the task of upgrading to new versions of our frontend platform to be time-intensive and frustrating.
With over 100 frontend services and nearly as many frontend engineers, it was clear something needed to be done in order to ensure that our platform was maintainable for Lyft’s growth.