add graphql endpoints to match the REST logic

[stan-dot]

Initial implementation towards DiamondLightSource/sm-bluesky#14

@Relm-Arrowny

[stan-dot]

@callumforrester the core team has people familiar with setting a graphql that works with the supergraph, I'd welcome your input

[callumforrester]

Without understanding the use cases I don't know if this is the right API, but as you say it's iter 1 (although please use a more descriptive PR title). I suggest someone from MX does the full review here.

[stan-dot]

@GDYendell I hear that you're the person to ask about the arcane details of supergraph integration, how to do this?

[GDYendell]

There are some docs on this here and you can look at https://github.com/DiamondLightSource/workflows as an example project that is already doing this.

[stan-dot]

@DominicOram I'll look into the supergraph docs to add it - there will be data export here as a CI job and a PR to the graph-federation repo.

in the meantime, is the implementation directionally correct?

[olliesilvester]

I'll look into the supergraph docs to add it - there will be data export here as a CI job and a PR to the graph-federation repo.

I wasn't sure if this actually needs to be exposed to the supergraph, but I guess it depends on what applications (other than BlueAPI) will be communicating with it. If it's only BlueAPI then I imagine we don't need to integrate it

[callumforrester]

I might suggest letting the API evolve a bit before exposing it, right now it is basically just a key/value store

[stan-dot]

@olliesilvester okay so no supergraph needed, then I'm moving on to work on making this ready for review

[olliesilvester]

Discussed with @stan-dot , closing this as stale since the config server is going in a different direction now