A Real-World Example

Starbucks’ Progressive Web App (PWA) is basically a single-page React app managed within a single repository. The GraphQL API is in another repository.

In practice, working on the UI that requires API changes means:

Having to npm link our API to our PWA. Working on the UI changes until real data is needed, then… Working on the API changes, until the UI is working again. Pushing 2 pull-requests for approval. Once approved, bumping & releasing the API first. Finally, bumping & releasing the UI.

There are a lot of places this process breaks down, especially on large teams with a lot of work in-progress.

But the real problem is that the repositories are splitting up features based on implementation.

Ideally, I’d like to see:

Working on the UI & API simultaneously.

(In practice, this expedites discovery & turnaround!) Pushing a single pull-request can be reviewed, approved, and tested. Once approved, the UI & API is shipped as a single feature slice.

A single repository, properly structured, can deploy to multiple hosts, as separate NPM packages, or as a single monolithic app.

How code is shipped does not have to mirror how it is developed.