How Lyft is migrating 100+ frontend microservices to Next.js ↦
The engineering teams at Lyft were facing some serious issues:
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.
With a team that large and the freedom to spin up a new microservice whenever the need arises, it must be terribly difficult to fend off divergence in coding architecture, style, tooling, and dependencies. Unless you unify everyone one a common foundation. A framework, if you will…
Sign in or Join to comment or subscribe