Separate GraphQL Service

[dylanmcreynolds]

Some of the challenges to introducing GraphQL to the AIMM project include:

• Many of the datasets in the metadata in AIMM do not contain metadata sufficiently rich to justify building a full GraphQL implementation for it
• GraphQL tools favor having a single endpoint for downloading the schema and issuing queries. Making a single endpoint for all of the experimental and synthetic data in the AIMMDb would be involve a lot of work at startup
• GraphQL does is not appropriate for downloading datasets, at least compared to tiled. GraphQL in this context is appropriate for finding and returning metadata

At the tooling update call, @danielballan brought up the idea of a middle ground that might allow us to demonstrate the utility of GraphQL. Some of the data sets in the AIMMDB (especially synthetic) do have rich metadata. We could:

• Greate a separate GraphQL service specifically for that dataset.
• Have a GraphQL schema for just those datasets
• The return fields can return a tiled URL to each dataset, letting client code be responsible for doing the data fetching in tiled and outside of GraphQL

This seems like a nice middle ground that builds a GraphQL implementation that could be useful for users trying to query the datasets that do have rich metadata structures. If this design proves useful, we could consider it for other datasets that have richer metadata structures. It also allows us to do this without force-fitting GraphQL into tiled or AIMMDB code directly.

I'm submitting this and assigning to @kleinhenz for consideration and comment.

[danielballan]

I endorse that summary of the conversation. :-)

Also, I like that this provides a concrete offer to experimentalists: "Here is an advanced search capability. Here is a demo of what it can do. Here is the (approximate) richness and rigor of metadata necessary to justify and support it. If you want this kind of advantage search, that's what you have to provide. Up to you!"