Repo Structure

Monorepo support

Coherence fully supports monorepos - each Application can have many services in its coherence.yml and one repo can host many Applications (using either the same or distinct coherence.yml files). 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).

Coherence can also be configured using globs in order to build only changed files on each deploy. See more info in the service config docs

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 may 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.

CI Pipelines

The services in the same coherence.yml will deploy in the same pipeline, with frontend services deploying after backend services. This is done so that the slower (backend) deploy happens first, and so that a frontend is never deployed expecting APIs that don't exist yet. You need to think about backwards compatibility when writing new APIs, however, since for a short time you may have the previous version of the frontend talking to the new version of the backend. App-wide blue/green deploys are on our roadmap to prevent this issue!

• You can guarantee atomic per-service deploy cycles by using multiple Coherence applications

Inter-service communication in a monorepo app

For example, let's say you have a Next.js app and a python flask app in the same repo, set up as 2 Coherence services in the same coherence.yml. The url_path of the Next.js service is / (the default) and the url_path of the python app is /api (these are set in coherence.yml and you have the freedom to configure them as you wish - these are just example values).

The Next.js frontend can find the backend:

• from javascript on the frontend from the browser at /api/ROUTE regardless of which environment it is on

The flask backend can know the frontend Next.js URL regardless of which environment it is on

• at https://{COHERENCE_ENVIRONMENT_DOMAIN}/ROUTE

Multirepo support

Each Application on Coherence can only be linked to one repo. You can, however, have many Applications. Each Application runs on its own domain, and is backed by distinct cloud resources. You can also use this pattern to deploy multiple apps from the same repo on different domains.

Inter-service communication in a multi-repo app

For example, let's say you have a Next.js app and a python flask app in 2 different repos, set up as 2 Coherence apps, each with their own coherence.yml.

• A common approach is to set an Environment Variable (e.g. BACKEND_APP_DOMAIN) in the frontend app with the default environment's staging or main branch environment URL in the backend app, and to override that value with a per-environment variable or with app logic when needed.
• If you have 2 apps in one repo, or use common branch names in both repos, you can also use app logic to determine the complimentary branch environment in one application from another application.

In this case, the Next.js frontend can find the backend:

• from javascript on the frontend from the browser at https://${BACKEND_APP_DOMAIN}/ROUTE regardless of which environment it is on
• at https://{BACKEND_APP_DOMAIN}/ROUTE from the Next.js backend regardless of which environment it is on