Fetch remote types from remote schema

Issues GraphQL
,
1

Currently we have to define all fields for remote types like:

type ComplexRemoteType @remote {
  id: ID!
  ... # very long list of fields
}

type Query {
   getComplexRemoteType(id: String!): ComplexRemoteType!
   @custom(
      http: {
          url: "URL_TO_EXTERN_GQL_SERVER"
          method: POST
          graphql: "query($id: String!) {getComplexRemoteType(id: $id)}"
     }
   )
}

Instead, I suggest to omit declarations for remote times completely by doing the following:

  1. Check if the returned type is present in the dgraph schema. If yes, do nothing and use it directly.
  2. If not, fetch the type from the remote server and copy all needed definitions.

This would lead to less errors as you don’t have to maintain two different files.

2

When a schema is uploaded, Dgraph will try to introspect the remote GraphQL endpoints on any custom logic that uses the graphql argument. From the results of introspection, it tries to match up arguments, input and object types to ensure that the calls to and expected responses from the remote GraphQL make sense. - Calling GraphQl custom resolvers

So basically this feature requests is asking to import the remote GraphQL endpoint types and inputs rather than needing to declare them again fully. This could be beneficial, but also lead to problems, what if the remote GraphQL endpoint types and inputs conflict with types and inputs declared or generated by the uploaded schema.

3

An error have to be thrown in that case and the developer need to act accordingly by not reusing the remote types. Do you think that this will be a problem? I think that this is currently not any different, although it is more explicit because you have to actually write down the remote types.

4

My personal opinion is that it could be problematic and cumbersome. There are many edge cases that would have to be handled or throw errors. On top of that, the generated schema with the remote types pulled in will have to take an account for differences of scalars between systems and how those are handled. One last quick thought is that the generated schema would happen on schema load, but there might be cases when the remote schema changes between those times and some really unexpected stuff happens.

I am not sure the best way to handle this, but I say we push it over to issues for a official feature request and let the devs review it.

5

That’s a really good point. Maybe we could have the best of both worlds by using the local type when one is declared using the @remote directive and fetch from remote, when the type is not declared.

Of course, as it is with many things, with power comes great responsibility.

Newbie question here: How exactly do we push this over to issues? is the “Issues” Category not enough?

6

It was tagged as question in the questions category. I moved it back to the Issues category removed that question tag and added the feature tag

1 Like
7

Alright, thank you!