Explanations

Repo Structure

Monorepo support

A monorepo has one or more services defined in coherence.yml. These services are all placed behind the same load balancer using path-based routing, and therefore are usually served by the same domain with each path routing upstream to a different upstream service (as defined in coherence.yml).

Each service has its own deployment and acts independently (e.g. scaling, connecting to resources). Sharing a repo does not mean that the applications are coupled in any technical sense. Currently, all services are deployed from a common pipeline, but that will change in the future.

An advantage of monorepos is that they allow atomic commits across services without version dependency issues. For a new project, they're a great choice.

Multirepo support

By creating multiple apps (each with their own coherence.yml), you can easily have multiple independently deployed and developed services, each with their own load balancer and therefore their own domain, routing to different services regardless of path (and therefore enabling each service to use the same path, if necessary).

This approach has advantages (such as the ability to have teams with totally different working & deployment cadences have services that talk to each other). It also allows for less contention on a single repo and makes integration testing easier at a high enough velocity.

It also has disadvantages, notably solving issues around different versions of services talking together for testing an integrated system.

Previous
Remote development with workspaces