Virtual fields

[tomschut]

Hi,

We've been trying to add a virtual field to our schema within the mechanisms set by prisma appsync and are running into some problems.

We've got a schema like this, generated from the prisma schema

type BlogPost {
   image: Image
}

type Image {
    width: String
    height: String
    apiKey: String
    ...
}

which we extend with an extra property, newImageObject, which is not present in the database schema.
So we've extended the graphQl schema like this:

extend type BlogPost {
  newImageObject: ImageObject
}

type ImageObject {
  w: String
  h: String
  url: String
 ...
}

with an after hook that picks up this field so that it can be constructed from the properties present.

This will produce an error in prisma since newImageObject is not a database column.

Our solution to this for now is stripping the field from the prisma args in a before hook (and adding the necessary properties that are needed to construct the virtual field in the after hook)

This solution is a bit inelegant, and I'd like to see if there's a better solution (to be made)

Unless there's already a better way I'd propose to support virtual fields by

1. having prisma ignore the fields that are not mapped to a database column
2. using the mechanism provided by appsync to connect a resolver to this field. This wouldn't work for the dev server in the current setup, but could perhaps be introduced, and if not an alternative like amplify appsync could be used to be able to run multiple lambda's as resolvers.

[maoosi]

@tomschut I did encounter the same issue for one of my projects and ended up doing same as you just described.

Have a look at this issue (and proposed API) and let me know what you think?

[tomschut]

That's exactly what we've been trying to build around the handler, and I think a more permanent solution like the API described in the issue would work.

I would however like to investigate (for another issue) a way to include not handling the field at all, so that a resolver other than (a custom resolver or hook of) the prisma appsync resolver can handle it. For this you'd still need to be able to omit a field and to select a context, and this context would then be picked up by a connected resolver.

The reason I'm thinking about this is so that more complex resolvers can run in their own lambda's and have their results cached.