Stream: graphql
Topic: Subscriptions
Florian Briand (Nov 22 2019 at 12:38):
Any opinion about how to use GraphQL Subscription system ? Maybe (probably) in coordination with FHIR Subscription resource ?
Grahame Grieve (Nov 22 2019 at 12:38):
what is that?
Florian Briand (Nov 23 2019 at 10:58):
GraphQL Subscriptions are another type of "entrypoint" you can have, alongside Query and Mutation, which is a event-driven entrypoint, where the server is pushing you the information when it change.
The strange thing is that they are not really talking about it in the documentation, but it's implemented in almost all servers and clients.
https://blog.apollographql.com/tutorial-graphql-subscriptions-server-side-e51c32dc2951
Grahame Grieve (Nov 23 2019 at 13:19):
Grrr this is a problem I’ve run into before with GraphQL - they’re not actually documenting stuff any more, they’re just coding it up. I can’t tell, from a quick read, if there’s more to that than a thin wrapper around typical restful subscriptions (just like the mutations stuff is)
Gino Canessa (Dec 12 2019 at 18:24):
I haven't delved too deeply in this yet, but initial thoughts:
-
It appears the transport mechanisms are left out of scope for graphql-subscriptions, so it would need to be plugged into the FHIR Subscriptions framework for distribution.
-
I am struggling to understand how they expect triggering to happen - it looks like they are based off query-results (similar to FHIR Subscriptions R2-R4), but expect servers to only run the queries when certain events fire?
-
I've been spending a lot of time considering GraphQL (and GraphDefinition) for FHIR Subscriptions (R5), and think it will be trivial to support (in systems that support it already). Specifically, adding a query to the subscription (e.g., an extension on
Subscription.channel.payload.content) lets a server evaluate the graph in the existing workflow. -
Many implementers have expressed concerns around security and what they return already (e.g., are only planning to support
emptyorid-onlypayloads at all), so I would guess it likely that clients will need to request the $graph on a returned id anyway.
Grahame Grieve (Dec 12 2019 at 18:58):
think it will be trivial to support (in systems that support it already)
I don't think it's trivial at all. The big issue for me is transaction boundaries - what does it even mean to evaluate a graphql function when processing a trigger? are you running graphql on that state of now, or the state of then? do you have to snapshot the entire database to run graphQL on it?
Gino Canessa (Dec 12 2019 at 19:48):
Valid questions, but those are being fleshed out already (e.g., specifying that returned resources are based on 'post-event').
Broadly speaking, one of the parameters of subscription processing is to be able to run out-of-workflow, so anything like a graph would be run at time of processing, and with that understanding it becomes trivial. This also more closely mirrors what a client would see (e.g., if a subscriber runs the graph after receiving a notification) and avoids a lot of sticky issues around security and privacy (e.g., if a resource was deleted, the server cannot assume it safe to send out a copy anyway).
On the other hand, trying to require graphs (or even just copies of instances) from before an update means that subscriptions are injected into the workflow of every operation on the server, which is neither scalable nor performant, and in some cases won't be implementable (e.g., a facade server processing events on the other side of the fence).
Grahame Grieve (Dec 12 2019 at 19:58):
anything like a graph would be run at time of processing
So that means that graph is (or can be) different to the 'after' copy of the resource?
Or is there some other expectation if a resource was updated again between the first update and getting to processing the subscription?
Gino Canessa (Dec 12 2019 at 20:17):
I had a long message debating the merits of both sides, but I don't think it matters.
If an update goes to a subscriber, it represents the 'best' state the server could send. If there was an update and then another, either the changes from the first update persist (so the subscriber has them), or they have been removed (in which case the subscriber shouldn't have done anything with them anyway).
So, either behavior from the server is acceptable.
The other side is that a subscriber may receive what looks to be the same notification (or graph) twice, but subscribers already need to accept that case - servers can send updates triggered on fields not visible to the subscriber.
Is there a case where this isn't true?
Last updated: Apr 12 2022 at 19:14 UTC
