Prisma1: Extend Type support for resolvers

[kbrandwijk]

• Add the possibility to reference any existing Type from a schema extension, e.g. any existing Type from the 'normal' Types, or a Type from another schema extension. Technically, everything is added to the same schema already, so this should just be a easy change in validation on saving a schema extension.
• Allow input Types in schema extensions

[kbrandwijk]

Also, allow field Types, like:

type AddressPayload {
  street: String!
  city: String!
  location: GeoLocation
}

type GeoLocation {
  long: String!
  lat: String!
}

[kbrandwijk]

@marktani Is there any workaround in any way to use anything but flat scalar fields for both input and in the return type? This is blocking for a number of integrations, where I need to pass in, and expect to return, a nested object. I can use Json in my payload Type, but that wouldn't give me any way to pick the return fields in the query... For the input, there seems to be no workaround...

[marktani]

I am not aware of a current workaround 🙂

[kbrandwijk]

Examples of integrations that I'm currently looking at that have either a complex input Type, or response Type, for which (nested) field Types would be really nice:

Weather API - has a complex response type
Google Directions API - has a complex request type and response type
SendCloud for webshop shipping labels - has a complex response type

Just a few examples. Using Json as return Type doesn't cover the fact that I would like to be able to pick (just like a regular query) which response fields I want. Using flat fields as input parameters is not workable for most of the API examples above either.

[sorenbs]

Thanks Kim - this is all something we want to add in short order.

We have some known issues with schema extensions that we want to address first, and then you should expect us to add this over the coming weeks.

[kbrandwijk]

Thank you @sorenbs. Referencing existing Types should be a seperate issue I guess, as that opens up a whole lot of new functional and technical challenges. For this FR, I think the focus should be: input Types and nested Types, like in the examples I gave (https://github.com/graphcool/feature-requests/issues/318#issuecomment-316826001 and https://github.com/graphcool/feature-requests/issues/318#issuecomment-318112472).

[sajsanghvi]

@kbrandwijk @marktani thanks. If you could support Enums in Schema Extensions that would be great as well

[daftgopher]

Right now I find it really challenging to query for an array of custom types. It would be really nice if we could do something like this:

// DOES NOT WORK:

type Book {
  author: String!
  title: String!
  description: String!
}

extend type Query {
  bookSearch(query: String!): [Book]
}

But because the [Book] type is unsupported when it's an array of the custom type Book, you need to query for an array of each of the individual properties like this:

// WORKS BUT IS KIND OF GROSS

type Books {
  authors: [String!]!
  titles: [String!]!
  descriptions: [String!]!
}

extend type Query {
  bookSearch(query: String!): Books
}

Which will give you back all the authors, titles and descriptions in one giant Books object with no clear indication of which properties are associated with each other (other than array indexes I suppose). Can we get something along the lines of the first example above? Would definitely make this kind of thing much easier, and more along the lines of how people probably want to store this data on the back end.

[marktani]

Sorry, forgot to mention this in our previous discussion, but returning a Json might be a tad bit less gross :P

type BookPayload {
  books: Json!
}

[daftgopher]

That's a good idea. Definitely a step in the right direction. The ideal
case would obviously still be to have the array of custom types but this
solves the problem of the data being disassociated when it's stored as a
payload instead.

On August 14, 2017 at 12:05:00 PM, Nilan Marktanner (
[email protected]) wrote:

Sorry, forgot to mention this in our previous discussion, but returning a
Json might be a tad bit less gross :P

type BookPayload {
books: Json!
}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/graphcool/feature-requests/issues/318#issuecomment-322232467,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1VMN-w0OK2kpO67Vq_sy2TQ3yqyXynks5sYHAsgaJpZM4OdelQ
.

[gaurav107]

https://github.com/graphcool/graphcool/issues/318#issuecomment-322232467

This solution has one inherent problem for client-side graphql libraries. For the following Schema Extension:

type BookPayload {
   books: Json!
 }
extend type Query {
  bookSearch(query: String!): BookPayload
}

If you were to use react-apollo on client side, the caching won't work since the books field is a Json array. apollo-client won't be able to create an entry in it's redux store based on each book's id as it'll treat it as simple Json, and cache normalization would also not happen. This leads to two issues:

1. Suppose there is a book that was returned as part of the above query. This query is linked to my search screen. Now I move to some other screen and trigger a mutation on the same book. Since apollo will treat the book listed on Search screen as just some random Json, it won't be able to make the connection based on book id, and hence, the updates won't get reflected on the Search screen.

2. Another challenge is, if the resolver you wrote in your Schema Extension is computationally heavy and you don't want to keep performing that operation, caching is a MUST on client side. For example: my resolver takes almost 2 seconds to finally return the response, and if I were to keep hitting the service without caching, it'll be really bad UX.

[kbrandwijk]

@gaurav107 The workaround to use a Json field type is no longer necessary, because the syntax proposed in https://github.com/graphcool/graphcool/issues/318#issuecomment-322230474 to return an Array directly from the resolver is implemented by now.

This FR was originally intended to address the use of other Types in both input and output for resolver functions.

[gaurav107]

@kbrandwijk I just went on with the books example that was being discussed here. What I really want is to be able to reference already existing types in my (normal) schema from an SE. Right now, if I do this:

type UserPayload {
  friends: [User]
  user: User
}

extend type Query {
  fetchUserAndHisFriends(someFilter: String!): UserPayload
}

It throws an error.
So I have to resort to the Json return type for both friends and user fields in the Payload. And as a result, client-side caching doesn't work properly

[kbrandwijk]

@gaurav107 In that case, your use case is exactly what this FR is about :+1:

[sorenbs]

I'd like to continue discussion in this proposal: https://github.com/graphcool/graphcool/issues/743

Please add a comment there if there are areas not covered yet :-)