Any chance of getting some more info around “Even though reactivity is not in the immediate plans”? Is it on the road map for the longer term?
Two things I was looking forward to in Apollo for Meteor apps was a) ditching Mongo for any SQL database and b) getting the same reactivity or close to it I am getting from Meteor with Mongo. Will “mixing Meteor subscriptions with your GraphQL queries” per the article only work if Mongo is the db?
Sorry if this isn’t the appropriate venue to ask but I can’t get around Medium.com’s circular email verification to post the question on the blog.
Yes it is! Before we recommend it as the official data layer for a future version of Meteor, we’ll have the reactivity story figured out. But in the short term, there are a lot of apps where real-time reactivity is not a requirement, and it’s easier to focus on that case first. (Note that you get get really far with polling/refetching though, so it’s possible that only a very small subset of apps requires true data streaming)
The FHIR standard requires that an Argonaut server specify a conformance statement on the /metadata route that describes the OAuth server’s functionality, and which REST endpoints it provides.
This functionality is provided so that FHIR clients can auto-configure themselves to the OAuth server’s implementation (it’s super awesome. Took awhile to get set up, but will be such a huge impact on healthcare IT in the future). If we were implementing polling between the FHIR server/client, that is the obvious spot to specify both polling and rate-limiting data. Basically, in the json object at /metadata, we would add a pollingInterval and rateLimit field that would tell the client how often to requery; and not to exceed a particular rate.
Just a thought. There’s a ton of awesome functionality that a /metadata route could provide to the Apollo server.