Pulling my hairs

Hi, trying to get some help, slowly getting there. 😉

I took your basic example, combining local and remote. It works really neat -but then I started to change the implementation

I simplified to two remote schemas, and the implementation is done with prisma and nexus.

When I stick the two, I get in igraphql

{
  "errors": [
    {
      "message": "Type PartyAccount must define one or more fields."
    },
    {
      "message": "Type Product must define one or more fields."
    }
  ]
}

I checked my code 20 times, replaces introspection with an sdl query. still the same result.

I trapped the fetch call… my two schemas are pulled properly as:

[server:start:gateway] >>>> SDL
[server:start:gateway] ### This file was generated by Nexus Schema
[server:start:gateway] ### Do not make changes to this file directly
[server:start:gateway] 
[server:start:gateway] scalar DateTime
[server:start:gateway] 
[server:start:gateway] type PartyAccount {
[server:start:gateway]   avatar: String
[server:start:gateway]   createdAt: DateTime!
[server:start:gateway]   id: String!
[server:start:gateway]   lastSeen: DateTime!
[server:start:gateway]   updatedAt: DateTime!
[server:start:gateway]   username: String!
[server:start:gateway] }
[server:start:gateway] 
[server:start:gateway] type Query {
[server:start:gateway]   me: PartyAccount
[server:start:gateway]   partyAccounts(
[server:start:gateway]     """
[server:start:gateway]     list of accounts
[server:start:gateway]     """
[server:start:gateway]     users: [String!]!
[server:start:gateway]   ): [PartyAccount]
[server:start:gateway]   sdl: String
[server:start:gateway] }
[server:start:gateway] 
[server:start:gateway] >>>> SDL
[server:start:gateway] fetching from http://localhost:4002
[server:start:gateway] >>>> SDL
[server:start:gateway] ### This file was generated by Nexus Schema
[server:start:gateway] ### Do not make changes to this file directly
[server:start:gateway] 
[server:start:gateway] scalar DateTime
[server:start:gateway] 
[server:start:gateway] type Product {
[server:start:gateway]   createdAt: DateTime!
[server:start:gateway]   name: String!
[server:start:gateway]   price: Float!
[server:start:gateway]   upc: String!
[server:start:gateway]   updatedAt: DateTime!
[server:start:gateway] }
[server:start:gateway] 
[server:start:gateway] type Query {
[server:start:gateway]   products(
[server:start:gateway]     """
[server:start:gateway]     list of accounts
[server:start:gateway]     """
[server:start:gateway]     upcs: [String!]!
[server:start:gateway]   ): [Product]
[server:start:gateway]   sdl: String
[server:start:gateway] }
[server:start:gateway] 
[server:start:gateway] >>>> SDL

Still the stitching doesn’t work…

Then I came across your example with nexus, there is commented code which says:

        // Or:
        //
        // resolve(buildSchema(data._sdl, { assumeValidSDL: true }));
        //
        // `assumeValidSDL: true` is necessary if a code-first schema implements directive
        // usage, either directly or by extensions, but not addition of actual custom
        // directives. Alternatively, a new schema with the directives could be created
        // from the nexus schema using:
        //
        // const newSchema = new GraphQLSchema({
        //   ...originalSchema.toConfig(),
        //   directives: [...originalSchema.getDirectives(), ...allStitchingDirectives]
        // });
        //

Do you think this applies to the above? I am thinking that it could be the DataTime scalar that breaks the schema parsing.

Just asking if you ever had similar issues,

Sincerely,

[gmac]

Btw, you don’t need those janky “IGNORE” comments with mergedTypeOptions to select preferred element definitions anymore, I actually removed that demo from the handbook recently. See https://www.graphql-tools.com/docs/stitch-type-merging#canonical-definitions

[gmac]

The real issue comes from the typeMergingOptions: {} construct - if I just comment it out, the types are properly constructed - with fields!

Hu, interesting. The way you had your type merging options looks generally correct at a glance, but something must have been off in there. That was the first thing I removed as well… When in doubt, simplify for the MVP. 😃 Anywho, good riddance to the manual mergers. The @canonical directive came about after building that example and recognizing what a poor development experience it is. If you ever want to know your code’s shortcomings, just document it. It’ll tell you!

Glad you’re up and running.