Idea: GraphQL Cache Parentage Description

[Robert O Butts <ro...@apache.org>]

I'd like to throw an idea out there: using GraphQL for cache parentage
description logic. This was actually @Jonathan_Gray's idea.

It can be unreasonably difficult to figure out why a cache is or isn't
parented to another (cachegroup parents, primary vs secondary, MSO,
algorithm, Server Capabilities, etc). I suggested some kind of parentage
UI. It'd be really nice if we had a UI and/or API explaining what parents
will be generated for each cache, and ideally why.

The problem is that putting it in a TO endpoint takes us back to not being
able to Canary Deploy. But putting the logic in Traffic Portal and the
Cache Config Gen means there's no single language library we can make, we'd
have to duplicate the code and logic (Sure, there are things like
Webassembly or Clojurescript, but they'd be a pain to write and maintain).

That's when Jonathan suggested GraphQL.

If we had GraphQL as an integral part of TC, we could write the Cache
Parentage logic itself as a GraphQL Query. Then, anyone who needed--namely
Config Gen and Traffic Portal--would use the same GraphQL Query source
code, make the query, and use their own code (Go, Javascript, etc) to build
the parentage model, and do what they need with it.

Anyway, it's just an idea. Feedback welcome.