Invoke a second request in "onSubgraphExecute" hook before query execution

[BabakScript]

Hi guys,

I have a use case that I handled before with GraphQL Mesh V0 and I need to re-implement that in Hive now after upgrading to Mesh V1.

I need to manipulate one specific query on a specific subgraph to inject an additional filter to the query on the fly before executing the query.

For this extra filter, I need to call another sub-graph to get the filter values on the fly.
Previously in the Mesh V0 I implemented that with the power of customResolvers so I created a resolver like this:

const resolvers = {
  Query: {
    myQuery: async (root, args, context, info) => {
      // 1. Call the first API to get filter values
      const filterResult =
        await context.New_Query_Subgraph.Query.FilterQuery({
          root,
          args,
          context,
          info,
          selectionSet: /* GraphQL */ `
            {
              results {
                filterId
              }
              httpDetails {
                sourceName
                responseTime
              }
            }
          `,
        });

      const filterIds: string[] = filterResult.results.map(
        ({ filterId }) => filterId,
      );

      // 3. Call Main API
      const mainCallResult =
        await context.Main_Subgraph.Query.myQuery({
          root,
          args: {
            ...args,
            // 2. Inject the filter list filterIds to Main Query
            context: args.context
              ? { ...args.context, filters: filterIds }
              : { filters: filterIds },
          },
          context,
          info,
        });

      return mainCallResult;
    },
  },
};

export default resolvers;

And set it in my .meshrc.ts like this:

additionalResolvers: [
    "./src/custom-resolvers/modified-resolver.js",
]

Now, with Mesh V1 and Hive as a gateway, as I checked, I need to create a custom plugin and use the hooks (probably onSubgraphExecute) to implement the same logic rather than customResolver. But as I realized, there is no SDK available in Hive to invoke the middle query. How can I invoke the middle query in my main query? (I mean the step one)

This is my draft plugin:

import { type GatewayPlugin } from "@graphql-hive/gateway-runtime";

const injectFiltersPlugin = (): GatewayPlugin => {
  return {
    onSubgraphExecute: async ({
      subgraphName,
      executionRequest,
      transportEntry,
    }) => {
      if (
        subgraphName === "Main_Subgraph" &&
        executionRequest.info.fieldName === "myQuery"
      ) {
        // 1. Call the first API to get filter values            <<< how can I invoke the extra GraphQL request here?
        // 2. Inject the filter list filterIds to Main Query     <<< (probably using setExecutionRequest)
        // 3. Call Main API (continue the execution)
      }
    },
};
};

export default injectFiltersPlugin;

[BabakScript]

Hi @ardatan, any suggestion for this?

[ardatan]

No we don't have any examples for that case.
InContext SDK is not intended to be used like that. I'd recommend you to keep using in the same way before.
If you still want to use it in that way, we can check it if you share a working minimal example of what you want to do in a sandbox environment like CodeSandbox.

[BabakScript]

Sure, I'll try to use additionalResolver, but I created a CodeSandBox to check that InContext SDK with you as I'm curious to see how that works in the new Mesh+Hive 😉

https://codesandbox.io/p/devbox/disscussion-571-wfsq5k

[BabakScript]

Hi @ardatan, did you get a chance to check my CodeSandbox? Do you need more information from my side or the sandbox environment I created is enough?

[BabakScript]

Hi @ardatan ,

Just a friendly follow-up here, as I imagine you have too many messages and probably missed my message here. 😉
Did you get a chance to check the sandbox environment here?

[ardatan]

Sorry I haven't had enough time to look at. But like I said, incontext-sdk is not intended to be used like that or onSubgraphExecute is not designed to get extra calls inside. You should use additional type definitions and resolvers.