I agree that GraphQL would be interesting, but to live up to developer’s mental models of it, they (at least the ones here at Karolinska) would likely want to be able to think that there is an active data store behind the scenes where you can pull up a composition and interact with it read+write on a specific field, or on a subtree in chunks, via GraphQL using “simplified” template-specific names + whatever other RM things that are unconstrained/unmentioned by the template. To do that I think a contribution builder approach would be good, where either an existing or new blank COMPOSITONs could be instantiated, read and modified and then, when finished, written back. Can we continue GraqphQL-discussion in that thread?
2 Likes