We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.
Another check we would like to have is fail if the count of deps exceeds a certain threshold (configurable in the workspace as per #78). The reason is we have seen cases where the service owner did not realize they were bringing in a massive graph of dependencies.
A specific case was when a service owner added a dependency on a certain SDK (a single dependency) not realizing that the SDK transitively brought in over 125 other SDK dependencies to support many APIs not needed by the service. They could have instead just brought in single, focused, SDK dependency instead.
We will need to pick a default value, which is overridable by attribute. We will decide on that value empirically using our internal collection of services, which provide a good sample.
We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.
Another check we would like to have is fail if the count of deps exceeds a certain threshold (configurable in the workspace as per #78). The reason is we have seen cases where the service owner did not realize they were bringing in a massive graph of dependencies.
A specific case was when a service owner added a dependency on a certain SDK (a single dependency) not realizing that the SDK transitively brought in over 125 other SDK dependencies to support many APIs not needed by the service. They could have instead just brought in single, focused, SDK dependency instead.
We will need to pick a default value, which is overridable by attribute. We will decide on that value empirically using our internal collection of services, which provide a good sample.