stitchSchemas with namespaced queries and mutations

[wmwart]

Good afternoon.
I have a question about using stitchSchemas with namespaced queries and mutations.
I have 2 remote services:

###AssetService
type Asset {
  id: ID!
  name: String!
  description: String
  ...
}

type AssetPayload {
  item: Asset
}

type AssetsPayload {
  items: [Asset!]
  pageInfo: PaginationInfo
}

input AssetWhereUniqueInput {
  id: ID
}

type AssetQuery {
  getOne(where: AssetWhereUniqueInput!): AssetPayload! @withAuth
  getList(filter: AssetFilter = {} sort: [AssetSort! ] = [{id: asc}] page: Int = 1 perPage: Int = 100): AssetsPayload! @withAuth
  getMany(ids: [ID!]!): AssetsPayload! @withAuth
}

type AssetMutation {
  create(input: AssetCreateInput!): AssetPayload! @withAuth
  update( where: AssetWhereUniqueInput! input: AssetUpdateInput!): AssetPayload! @withAuth
  remove(where: AssetWhereUniqueInput!): AssetPayload! @withAuth
  restore(where: AssetWhereUniqueInput!): AssetPayload! @withAuth
  delete(where: AssetWhereUniqueInput!): AssetPayload! @withAuth
}

type Query {
  Asset: AssetQuery
}

type Mutation {
  Asset: AssetMutation
}

...

and

### AssetClassService
type AssetClass {
  id: ID!
  name: String!
  assets: [AssetWithoutAssetClass!]!
}

type AssetClassPayload {
  item: AssetClass
}

type AssetClassesPayload {
  items: [AssetClass!]
  pageInfo: PaginationInfo
}

type AssetClassQuery {
  getOne(where: AssetClassWhereUniqueInput!): AssetClassPayload! @withAuth
  getList(filter: AssetClassFilter = {} sort: [AssetClassSort! ] = [{id: asc}] page: Int = 1 perPage: Int = 100): AssetClassesPayload! @withAuth
  getMany(ids: [ID!]): [AssetClass!]!
}

type AssetClassMutation {
  create(input: AssetClassCreateInput!): AssetClassPayload! @withAuth
  update( where: AssetClassWhereUniqueInput! input: AssetClassUpdateInput!): AssetClassPayload! @withAuth
  remove(where: AssetClassWhereUniqueInput!): AssetClassPayload! @withAuth
  restore(where: AssetClassWhereUniqueInput!): AssetClassPayload! @withAuth
  delete(where: AssetClassWhereUniqueInput!): AssetClassPayload! @withAuth
}

type Asset {
  id: ID!
  assetClass: AssetClass
}


type AssetQuery {
  getMany(ids: [ID!]!): [Asset!]!
}


type Query {
  AssetClass: AssetClassQuery
  Asset: AssetQuery 
}

type Mutation {
  AssetClass: AssetClassMutation
}

Thus, when using stitchSchemas in my proxy service, a function for obtaining a stitched schema appeared:

const makeGatewaySchema = async () => {

  const assetServiceExecutor = makeRemoteExecutor('http://localhost:7702', { log: true });
  const assetClassServiceExecutor = makeRemoteExecutor('http://localhost:7703', { log: true });

  return stitchSchemas({
    subschemas: [
      {
        schema: await introspectSchema(assetServiceExecutor),
        executor: assetServiceExecutor,
        merge: {...}
      },
      {
        schema: await introspectSchema(assetClassServiceExecutor),
        executor: assetClassServiceExecutor,
        merge: {...}
      },
    ],
  });
}

Which allows me to fulfill the request:

query Items {
  Asset {
    getList {
      items {
        id
        name
        assetClass {
          id
          name
          description
        }
      }
    }
  }
}

However, none of the combination of merge options of these subcircuits specified in the documentation and examples of use returned me the required answer.
I assume that the problem is precisely in the namespaced types.

Please help me specify the correct settings for merge options or share a link to a solution to a similar problem

[yaacovCR]

Hmmm. I guess you are having trouble merging types that don’t have any keys like your wrapper types. This should definitely be possible and if it isn’t, you can probably create a custom merge resolver that does it? It might be a feature request, I will have to take a deeper look. A reproduction might help to get things going

[wmwart]

@yaacovCR, thanks for the answer! I hope you will help put everything in its place.
Here is a repository with two examples: https://github.com/denisgnt/gateway-service-example.
The main branch contains an example of a non-working request.
The feature-work branch contains an example that works, but in which the schemas of our services have been converted to the form that is offered in graphql-tools.
This raises questions:

1. Graphql-tools doesn't fully support the grapgql spec? We looked at the source code and found out that using namespased queries or mutations is not supported out of the box. In addition, nested response types (see AssetsPayload) for automatic splicing of the result are also not supported.

query getListAsset($filter: AssetFilter){
        Asset {
            getList(filter: $filter) {
                items {
                    id
                    description
                    createdAt
                    assetClass {
                        id
                        name
                        description
                    }
                }
            }
        }
    }

{
  "filter": {},
}

2. How to change the direction of requests depending on the passed parameters? For example, filtering the Asset list by ids will first send a request to AssetService, then to AssetClassService

query getListAsset($filter: AssetFilter){
        Asset {
            getList(filter: $filter) {
                items {
                    id
                    description
                    createdAt
                    assetClass {
                        id
                        name
                        description
                    }
                }
            }
        }
    }

{
  "filter": {
      "ids": ["ID0001", "ID0001"]
  },
}

However, if I need to filter this request by the field that is in the AssetClassService, then I need the request to be executed in the opposite direction: first in the AssetClassService, then in the AssetService.

query getListAsset($filter: AssetFilter){
        Asset {
            getList(filter: $filter) {
                items {
                    id
                    description
                    createdAt
                    assetClass {
                        id
                        name
                        description
                    }
                }
            }
        }
    }

{
  "filter": {
      "assetClass": {
          "id": "GRP_T1"
      }
  },
}

How can this be done?

3. Custom mutations. This is why we came from apollo-federation to graphql-tools. We are planning to use a GatewayService based on graphql-tools as some implementation of the saga microservice architecture pattern. That is, it will contain some business logic that will be responsible for mutations that should affect several remote services. For example, the creation of an Asset should leave its mark on a few more services. So, to the existing remote services in the GatewayService, we plan to add a local schema with the addition of a mutation, which will contain a custom AssetCreateInput to implement the necessary logic.

mutation createAsset($input: AssetCreateInput!) {
  Asset {
    create(input: $input) {
      item {
        id
        name
        assetClass {
          id
          name
        }
      }
    }
  }
}

How to replace the mutation existing in the remote service with the mutation of the same name from the local schema?

[yaacovCR]

1 we find one subservice for each field as we go, so if you have overlapping namespace, it should pick one, and then should automatically select appropriate subservice for each field just like Query. have to take a closer look to see why this is not happening

2 using different as subschemas depending on argument is tricky, maybe you could use transforms to rename subschemas and then introduce on gateway a custom merge resolver that delegates as appropriate

3 you should be able to pass additional typedefs and resolvers to s to stitchschemas

[wmwart]

1. I didn't understand the answer. Is the problem on the graphql-tools side or do we need to pass additional stitching parameters?

2. Why use renaming for schemas? Now we are using a fully customizable resolver, in which we use if else to determine which of the services to send the request to. But this approach cannot be scaled. With the growth of the number of services and parameters, such a resolver will turn into a monster.

[yaacovCR]

1 not sure yet
2 agree, see comment below, no need to rename. What kind of config do you propose? We are very open to new ideas/PRs!

[yaacovCR]

In 2 transforms to rename fields for each subschema. Or maybe the custom merge resolver would figure it out without renaming