Packages to use composition, not inheritance
GraphQL does not have inheritance, so it is an anti-pattern to use it to model polymorphism in our models. The correct approach is to model polymorphism as implementation of interfaces. Here there is a single `PackageType` interface, and then different implementations of that. Since the package types only differ in their metadata, we move the polymorphism down to the metadata fields, which an empty interface, implemented by metadata types. One thing that had to change was the `Query.package` field, which was previously `Query.package_composer_details`. This must change since the implementation of the lookup does not perform any type checking, and thus we cannot type the return value as a composer package. This would be an illegal and ill-typed down-cast. A good analogy for this is having a Java collection of ```java // yes, Cucumbers are fruits - look it up List<Fruit> bowl = List.of(new Apple(), new Banana(), new Cucumber()) ``` And then expecting to get an apple without a cast: ```java Apple fruit = bowl.get(0) // bad ``` This code would fail to compile in Java, and it is equally illegal in GraphQL, without the appropriate casting. We mark the composer metadata type as an orphan since it is only refered to as an implementation of the broader metadata type. We also split the type of packages into a top-level one, which is able to refer to versions, and a leaf node which may not. This prevents unbounded mutual cyclic recursion. Return successfully for all packages We can gradually add more specific package types, but it is important to always succeed with the data we can return.
Showing
Please register or sign in to comment