In case anybody is interested, the HL7 Standards Group has started a fairly lengthy conversation about the FHIR spec (Fast Healthcare Interoperability Resources) supporting GraphQL queries, and we’ve been able to direct them towards an Apollo demo. Relevant for people in the healthcare industry or working on healthcare apps.
https://chat.fhir.org/#narrow/stream/implementers/topic/GraphQL
HL7 is managing the process to get FHIR and other web standards (OAuth, OpenID) adopted by standards organizations such as ISO and IEEE for use in healthcare. Once they get FHIR to normative version, it will basically be an international standard for ~10 years. If you’re interested in the future of GraphQL and Apollo, might be worth checking out.
4 Likes
There was an excellent Meteor Night yesterday in Santa Monica. @abhiaiyer spoke and I had the impression that he may have been saying that there is no security for data sent and received by GraphQL, but that it could easily be added. Does the Apollo Demo you linked address this in any way?
It looks like it uses the passport and ACL packages, so presumably, yes. I haven’t had time to dive deep into this demo; but one thing I would point out is that the FHIR standard specifies the use of OAuth and OpenID. So, passport would need to be updated with passport-oauth before it could be considered FHIR compliant. But getting the passport middleware staged is certainly a step in the right direction.
1 Like
Relaying a few questions that one of the FHIR architects has been having about mutations, error codes, and batch operations in GraphQL and Apollo. Anybody know of API specs that address these issues?
so. finally, time to talk about mutation. my preferred approach would be that you could update a resource directly, but:
but nothing. I read something wrong. So create/update/delete.
but so many questions - are a set of mutations a batch? a transaction? How can you create a set of related resources?
duh. no multiple mutations
I’ve been reading the graphQL spec about mutations, and am unclear on error handling. Here’s questions I put on the graphQL chat:
if execution fails, should a server return 200 OK with { “error” : ["…"] }? or should it have a different response code?
This forces a client have to handle HTTP errors (before you get to the graphQL processor), and also check for 200 OK + errors - why is that useful?
under what conditions would your response include both data and errors, and what should a client do with that?
the documentation helpfully says “If no data is returned, according to the GraphQL spec, the “data” field should only be included if the error occurred during execution” - I’ve read that several times, and I don’t know what it means, either returning data if there is no data returned, or what the definition of ‘during execution’ is
I just upgraded my server to fix a mistake in every response.
@awatson1978 Pinging @sashko re: these questions. It may also be helpful to ask about them on the Apollo Slack channel.
Preparing to bounce over to the FHIR forums, and announce we have an architecture design for GraphQL queries.