[SOLVED] Extracting query parameters from previous query output


GraphQL has input types that are separated from output or types for a reason.

However, in some cases, I want to build a query based on the returned values of a previous query.

Specifically, when calling

requestHealthPolicy(productCode: "HCP",
    planInsurer: "SMJ", .... ){

I really want to wrap the parameters {productCode, etc}
into an input object which I can load from the database.
However, when I do the corresponding query i.e.


I have some naming mismatch between the fields returned by the first query and the parameter fields required by the second query. Plus, some hirachy mismatches that need to be be cleaned up.

When the field names of the first and second query are all identical, I can create a different return type with a subset of the fields but because that type is an output type, I cannot pass it on as input type. Ok, that's a logical consequence of separating input from output types, but not exactly fun to work around.

Currently, the only way to do this, is effectively, casting the problem to the client by first loading, then matching fields, and then calling the requestHealthPolicy with the paramters previously extracted.

Practically, all I want is to pass the ID around and then, internally do the load, match, & call of the request query.

By that, I want to add a higher level of abstraction over the API in the sense of only asking for ID's from the public API endpoint, but underneath calling various
internal queries and mutations before returning the final result to the client. By that, I want to shield the client as much from internal (sensitive) data which aren't needed for the client request, but required for internal processing.

In other stacks, you simply write a bunch of functions that call existing queries and put them together as needed.

For some reason, I just cannot figure out how to implement that in the GradnStack with a custom resolver or similar.

Any ideas or pointers?

In the GRANDstack you can write your own custom mutations and queries using Cypher to accomplish this. You can explicitly state when you want to take as input for the query and what you want returned. In this way, with Apollo Hooks you could then string together the functions you're after. So lets say you need to string those queries together then you can just call:

const {data, loading, error} = useQuery(yourCustomQuery);
const [useCustomMutation, {data}] = useMutation(yourCustomMutation)
if (loading){
    return loading

const neededData = Data.neededData;

useCustomMuatation({variables: { type: neededData}}).then
etc, etc, etc.

I hope that helps.

Doesn't work.

Defined the following function to fetch data from my custom query, like so:

async function getPlanInput(planID) {
    const GET_HPLAN = gql`
      query healthPlanByID($planID: String){

  const { loading, error, data } = useQuery(GET_HPLAN);
  if (loading){return loading}
  if (error) return  error.message;

  const planData = {
      productCode: data.planType,
      //planInsurer: data.plan_provider{Provider{provider_id}}
      planType: data.name,
      premium: data.plan_rate,


  return planData

And within the customer resolver, I call it like any other async function

            let plan = await getPlanInput("smj-plan-c-23");

Getting the following error:

    "message": "Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
\n1. You might have mismatching versions of React and the renderer (such as React DOM)
\n2. You might be breaking the Rules of Hooks
\n3. You might have more than one copy of React in the same app\nSee https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.",
  • Don't use any renderer.
  • Have only one copy of React

Evidently, I am breaking the rules...

Why do I need React on the API server in the first place?

Looks like I have to write a good old query generator myself and embed a graphql client to query my own API server to do control flow because there is no working way to do IPC.
This is completely and uttermost insane.


As stated above, a custom query generator with a client embedded into the index.js did the trick.