I know @ian.mcnicoll has mentioned thoughts regarding GraphQL for openEHR.
Regarding data retrieval I believe several openEHR CDR implementations have ways to combine (e.g. nest) AQL queries and/or merge responses on the server side thus reducing number of (http-)calls (@bna can probably link to some of DIPS stuff).
In the paper Applying representational state transfer (REST) architecture to archetype-based electronic health record systems | BMC Medical Informatics and Decision Making | Full Text (long time ago now) we showed an example where we embedded AQL inside XQuery inside HTML…
Warning: Below I go off topic from the “AQL” part of the topic…
I think there is definitely room for GraphQL in the openEHR space, especially regarding gradually constructing input data (possibly several related COMPOSITIONs) to later be submitted as a big CONTRIBUTION object into a CDR/backend. I’d suggest making something like the “contribution builder” described in part of the same BMC REST-paper linked above, and make sure that it in addition to the “raw” (verbose) canonical openEHR JSON (and/or XML) format also can use something like the simplified template specific “structured” openEHR-format (then IDs of specific templates of course need to be provided).
If we can make a multi-user contribution builder, then it could likely make it easier for developers to create multi user + multi-device input UI’s. We need this for example in emergency wards where you have a team simultaneously documenting different parts regarding the same patient. Best user experience would of course be something based on “Operational Transformation” (the same algorithm as Google Docs uses) but multi-device sync via GraphQL could come a long way too, if implemented in an efficient way.