In the end, we want the client to work with a schema that has an array of notes at the order level.
It sounds like there are two paths to this:
- Keep the schema in its current form, shifting the responsibility of the notes being part of the Order service (not Service A or Service B).
- If Service A and Service B truly do need their own notes data, then I’ll have to adjust the schema so that those services expose their own notes array on the hierarchy, then on the client shape the data returned by graphql endpoint to match the final schema (i.e. combine those individual note arrays into one).
We do have a reason for wanting the notes that relate to the service to also be stored and managed within that service. I was just hoping that the query builder had some way, perhaps with a custom directive, that allowed multiple services to provide the contents of an array, then combine them all together before sending down the client. It would save us from having to the data shaping on the client after receiving the graph data.
We will probably take a look again and see if we want to store the notes in its own service and not spread out over the different services.
Perhaps this can be a feature request to enhance the federation service, introduce a federation directive “@concat” or something like that, so that the query plan knows to call each service and concat the results for that field from each service into a single array.