0

I have a graphql api that wraps multiple software systems. Right now I have all the types listed directly under query with a prefix for the software system. Eventually each software system could have hundreds of types.

query {
    ERP_ItemMaster (partId: Int!): ItemMaster
    ERP_SalesOrder (doc: Int!): [SalesOrder]
    ERP_PurchaseOrder ...
    ERP_WorkOrder ...
    Warehouse_Type1
    Warehouse_Type2
    ShopFloor_Type1
    ShopFloor_Type2
    SupplierQuality_Type1
    SupplierQuality_Type2
}

type ItemMaster {
    field
    field
    ...
}

type SalesOrder {
    field
    field
    ...
}

...
...

This works fine really. When I'm in GraphiQL I start typing "ERP_" for example, and the suggestion box limits it to the types/queries for that system.

I'm wondering if it's possible to add a layer under query to group the types by software system.

When querying, instead of:

query {
    ERP_ItemMaster(partId: 12345) {
        field1
        field2
    }
}

I would have: 

query {
    ERP {
        ItemMaster(partId: 12345) {
            field1
            field2
        }
    }
}

I'm getting stuck on the resolver at the grouping level - ERP in the example above. It would need to somehow wrap all the resolvers for the sub-types on that system - instead of the one resolver for each type under the top-level query.

The schemas:

type Query {
    ERP: ERP
    Warehouse: Warehouse
    ShopFloor: ShopFloor
    SupplierQuality: SupplierQuality
}

type ERP {  // What does the resolver look like for this?
    ItemMaster(partId: Int!): ItemMaster
    SalesOrder (doc: Int!): [SalesOrder]
    PurchaseOrder (doc: Int!): [PurchaseOrder]
    WorkOrder (doc: Int!): [WorkOrder]
}
type ItemMaster { ... }
type SalesOrder { ... }
type PurchaseOrder { ... }
type WorkOrder { ... }

type Warehouse { ... }
...
...
...

type ShopFloor { ... }
...
...
...

Is it possible? If so, is it even a good idea, and what would the resolver at the grouping level look like?

If you have suggestions on a completely different way to organize it, I'm open to that too. I like the idea of having one end-point and being able to access all the company's data from there, but maybe a separate graphql end-point for each system would be better?

Thank you!

bottomsnap
  • 221
  • 2
  • 5
  • As discussed [here](https://stackoverflow.com/a/54463837/6024220), the resolver for each `Query` field (`ERP `, `Warehouse`, etc.) will need to return an empty object for this to work. – Daniel Rearden Jul 19 '19 at 15:08
  • I'm marking this question as a dupe because the pros and cons of this approach are covered by the answers in the dupe target, even if that question was specifically asking about mutations. I'm happy to provide additional context if those answers don't shed enough light on your concerns. – Daniel Rearden Jul 19 '19 at 15:08
  • I'm missing something. Do I need to do anything else in the ERP resolver to link it to the resolvers for ItemMaster, SalesOrder, etc. before returning the empty object? Or if I have separate resolvers for ItemMaster, SalesOrder, etc. under the root, graphql should know to call those even though they're not directly under query, and I just should return the blank object in the ERP resolver. Thanks again. – bottomsnap Jul 19 '19 at 16:16
  • How are you building your schema? Using `apollo-server` or `graphql-tools`? Using `buildSchema`? – Daniel Rearden Jul 19 '19 at 16:44
  • I'm using buildSchema – bottomsnap Jul 19 '19 at 16:58
  • 1
    While it's technically possible to work with buildSchema, I would [strongly advise against using it](https://stackoverflow.com/a/53987189/6024220). You can't easily define resolvers for anything but the Query type if you use `buildSchema`, and in this case you need to define resolvers for all your grouping types. If you want to use SDL to define your schema, it's much less of a headache to just [use graphql-tools](https://www.apollographql.com/docs/graphql-tools/generate-schema) – Daniel Rearden Jul 19 '19 at 17:04

0 Answers0