How to handle services dependencies

[josecelano]

IMPORTANT: this discussion is not only about the Torrust Tracker. It involves all the software repositories in the Torrust organization that have a dependency relationship.

Yesterday @da2ce7 @WarmBeer @cgbosse and @josecelano discussed the best way to use versioning to solve the service's dependencies. I will first go over the problem we're trying to solve, and then you can reply with the proposal for solutions.

Repositories

We have these repositories that are using Semantic Versioning to tag releases.

• Torrust Tracker: https://github.com/torrust/torrust-tracker v2.3.1
• Torrust Index Backend: https://github.com/torrust/torrust-index-backend v1.0.0
• Torrust Index Frontend: https://github.com/torrust/torrust-index-frontend v2.0.0

Deployable services

To explain the problem, I will assume a given configuration on production. For example:

You run the tracker with the following services:

• The UDP tracker
• The HTTP tracker
• The tracker API
• The database using a MYSQL instance (v8.0)

The index backend with:

• The backend API
• The database using a MYSQL instance (v8.0)

The index frontend with:

• The backend web server (serving the SPA).

The units of deployment are:

1. The database for the tracker using a MySQL instance.
2. The tracker (with the three running services).
3. The database for the tracker backend using a MySQL instance.
4. The tracker backend (win the API).
5. The tracker frontend using a web server to serve the SPA.

The scope of this discussion is the static dependency between services, not the dependency on deployments. You should deploy those services in reverse order of dependency, first the tracker, then the backend and finally the frontend.

These deployment units are the only ones with a version tag.

Running services dependencies

Even if we have only 5 deployable artefacts, their dependencies are more complex because the tracker has three running services. The dependencies at runtime are:

• The tracker depends on a concrete DB schema in the MySQL instance.

• The index backend depends on a concrete DB schema in the MySQL instance.

• The index backend depends on a concrete version of the tracker API.

• The index frontend depends on a concrete index backend API version.

• The BitTorrent clients depend on the UDP tracker protocol specification

• The BitTorrent clients depend on the HTTP tracker protocol specification

Problems

Scenario 1

Since the tracker has 3 services, any breaking change on any of the services should change the major version of the tracker.

For example:

• We change the API adding new breaking changes going from v3.0.0 to v4.0.0
• We upgrade the UDP tracker by implementing a new BEP. We change the version to v4.1.0

In this case, we force all index backends to upgrade to the latest API changes, even if users are only interested in using the new BEP feature.

Scenario 2

• We add a breaking change to the backend API.
• We deploy the backend.
• The frontend is not going to work.

If we keep backward compatibility and use versions at runtime for the API, this should not be a problem. It's only a problem if we want to stick one frontend version to one index backend version. That means we should add a dependency in the frontend with the backend version.

Scenario 3

Same as "Scenario 2" but between the index backend and the tracker API.

The index backend depends on the tracker API.