legumeinfo / graphql-server

A GraphQL server that supports the Legume Information System and related biodata websites
Apache License 2.0
2 stars 3 forks source link

Resolving generic types like SequenceFeature (from mine references and collections) #131

Closed sammyjava closed 8 months ago

sammyjava commented 9 months ago

One reason I'm experimenting with generic types like SequenceFeature as resolvable types is that there are many collections in the mines that are of generic Annotatable, BioEntity, and SequenceFeature objects, a situation we haven't yet dealt with.

An example is SequenceFeature.childFeatures. Gene and MRNA have child features, which are referenced as SequenceFeature objects (actually Exon, CDS, MRNA, ThreePrimeUTR, and FivePrimeUTR currently).

Another big one is BioEntity.locatedFeatures where each locatedFeature is a Location which contains a feature reference to a BioEntity (whatever it happens to be).

This is a huge power of the mines, in that things can be related that aren't the same exact type. For instance a BioEntity like Chromosome has sundry locatedFeatures of various types (Gene, Exon, UTR, etc.)

We could expand graphql-server by writing a zillion resolvers so that we'd have separate resolution of Gene child mRNAs and MRNA child exons in the first example, and exons, genes, mRNAs, etc. in the second example. I think that is a Bad Idea.

Rather, one would like to query "What things are ontological children of this gene?" or "What things are located on this supercontig"? For that we need to resolve generic types like BioEntity and SequenceFeature.

I post this issue because we currently have SequenceFeatureFactory, for example, which is used to resolve the SequenceFeature interface bits of things that implement SequenceFeature[Interface]. But the way it's written, I can't simply resolve a SequenceFeature given its identifier. It seems that I need to write a regular resolver of the (new) type (not interface) SequenceFeature using the resolver syntax we have for, say Gene. Then, I guess, we could use a SequenceFeatureInterfaceFactory in the way we are currently using SequenceFeatureFactory to resolve the SequenceFeature[Interface] references and collections.

OR, likely, there is a better way of doing it. I am convinced that I want to resolve BioEntity and SequenceFeature as such, since they are directly referenced in mine references and collections. Without it, I get something that looks like this, because the child feature is a SequenceFeature and I don't have a resolver for SequenceFeature.

image

sammyjava commented 9 months ago

To pursue this idea, I have a branch resolve-generic-types that resolves Annotatable, BioEntity, and SequenceFeature (by id parameter). This works fine, and I renamed the interface factories AnnotatableInterfaceFactory, etc. The above situation is now resolved: image

sammyjava commented 8 months ago

Closing this since we covered it and I'm now coding the implementation using the HasStuff interface concept and getters that use an id parameter.