Update GraphQL API to be compatible with the graphql-transport-ws protocol

[rjwills28]

Coniql currently uses the tartiflette API to implement the GraphQL server. This uses the deprecated subscription-transport-ws protocol 'graphql-ws'. GraphQL clients are encouraged to move from subscription-transport-ws to graphql-ws (see DiamondLightSource/cs-web-lib#13). The graphql-ws library uses the 'graphql-transport-ws' protocol, which is not supported by tartiflette, therefore we need to move to a different API.

[rjwills28]

I have had a look at some options. There seem to be very few that support the new graphql-transport-ws protocol. Perhaps this will change is people move away from subscription-transport-ws. There also seem to be 2 types of GraphQL APIs - code-first and schema-first. The current Coniql (tartiflette) implementation uses schema-first - i.e. we define a schema in sdl format. Code-first APIs instead write the scheme into the code. It is unclear to me which way is best (there is plenty of discussion about this on the internet). All I can say is that it will potentially be a bigger job to convert to code-first as we will have to convert the schema sdl files into python.

Here are some options:

Code-first:

• Graphene
• Strawberry - I've actually started playing with this one trying to get a Query through Coniql working. No luck yet but this does seem quite well documented and supported.

Schema-first

• Tartiflette - uses subscription-transport-ws
• Ariadne - uses subscription-transport-ws but making changes to handle graphql-transport-ws: Implement graphql-ws protocol support mirumee/ariadne#837. There is a fork with the changes but they have not yet been merged into the main repo.

[coretl]

What we have used elsewhere:

• https://github.com/wyfo/apischema for code-first graphql schema generation
• https://github.com/dls-controls/graphql-ws-aiohttp for the ws subscription

[coretl]

Code-first conversion will be fine as we are moving in this direction for other projects, and we can delete half the schema (the device bits) as we do that

[coretl]

@callumforrester may also be interested in this...

[AlexanderWells-diamond]

I'm also interested, as I have a WebUI that talks to Coniql as well as my own webserver, so will have to migrate at the same time as Coniql does.

[coretl]

https://github.com/dls-controls/scanspec/blob/master/src/scanspec/service.py

[rjwills28]

I have been playing around with Strawberry and have created a test server with some of the basic Coniql abilities, namely querying and subscribing to a PV value.

This is available here if anyone wants to take a look at how it works: https://github.com/rjwills28/coniql_strawberry.

One great thing about Strawberry is that it supports both the old and new protocols (graphql-ws and graphql-transport-ws).

I can run it against cs-web-proto by modifying the client subscription to only ask for the value field and using the old protocol. Next I will see if I can get cs-web-proto running with the new protocol.

[rjwills28]

A quick note about web clients:

• GraphiQL: this uses the old protocol from subscription-transport-ws so cannot be used to test the new protocol.
• GraphQL Playground: also current only supports the old protocol but it look like work is being done to support the new one (see Ability to use graphql-ws instead of subscription-transport-ws graphql/graphql-playground#1291)
• Altair: the GitHub issue above recommends this client which supports both protocols: https://altair.sirmuel.design/#download. I have provided instructions on how to use this client in the readme of coniql_strawberry

[callumforrester]

@DiamondJoseph may also have input on web clients.

[DiamondJoseph]

Altair was what we settled on when doing exactly the same switch of protocols. The browser plugin is convenient, simple integration with express middleware, which was what our frontend was, but your mileage may vary.

[rjwills28]

I found an issue in the Strawberry source code which leads to a memory leak when unsubscribing from PVs updating at high rates. Please see this issue for details: rjwills28/coniql_strawberry#2

[rjwills28]

Done in move to use the Strawberry GraphQL API, which is compatible with both old and new websocket protocols (PR #44).