Query which beamlines are available

[callumforrester]

As a user I would like to be able to query which beamlines have configurations so that I can build queries in a discoverable way.

Acceptance Criteria

• I can run a GraphQL query that tells me the names of beamlines with valid configurations for this service

[tpoliaw]

As a user

As an admin?

[tpoliaw]

And RE good first issue, are you volunteering?

[callumforrester]

I might well give it a go, yes, and we should start with admin, but do you think there's value in a query for a regular user being able to ask if their beamline, that they have permission to view, is supported?

[tpoliaw]

With the current set of OPA rules, a regular user has no concept of 'their beamline'. It'd probably be possible to build a list of beamlines they've previously been on a visit on but it's questionable whether having been on a visit a year ago should still allow them to query beamline info.

For the original ticket, there was an all_beamlines method removed in b234940 that could be reinstated to get part of the way there.

[callumforrester]

The other consideration is whether to make a new configurations query or simply expand the configuration one to return a list of configurations (where list size would be 1 for most use cases). The latter is simpler and probably more graphql-ish, since it allows for client-driven queries, the former aligns more the desire to separate "admin" queries from "user" queries.

I'll probably expand the existing query unless you have strong feelings.

[tpoliaw]

That'd make sense. Make the beamline an optional input (renamed to filter?) and if absent return everything?

Or if you want to make the query more complicated but potentially more useful, have an optional field for each configuration option and only return the matching ones? It could be useful to be able to query for 'all beamlines that use template XYZ'.

On the other hand, there's a decent argument for not adding anything until there's an actual use for it.

[callumforrester]

Yeah probably best not to overpredict. I think more complex queries can come from separate tickets. I'll just make a filter for the beamline for now.

On names we will eventually have to reconcile the names in this API with conventional names for entities in the supergraph (so off the top of my head we'll need to rename beamline to instrument in the API) but that can also be a separate ticket as-and-when.