eg. I’d like to have an

activityFeed

field on a

User

, but I want it to return a type that doesn’t exist in the DB, built up of related data from various tables and logic..

you'd built a GraphQL Server in front, using prisma-binding and schema stitching

Yup, I’ve done that (as in, I have another GraphQL server in front). So do I have to completely re-model the

User

type from scratch?

well, you can. not sure what you mean

Right, gotcha. What about all the resolvers? Same again, redefine them all?

yes and no. I recommend studying this example in detail https://github.com/graphcool/graphql-server-example 🙂

@nilan so for example

type Experience

is defined in both schemas, because in the Prisma-layer it has a

host: User!

field, but it’s removed in the API-layer.

So how does it know how to resolve that field

your resolver implementation 🙂

@nilan That’s what I’m saying, where is the resolver for

reviews

in the example app? There doesn’t seem to be one! So it does it get the one from the generated Prisma code?

can you elaborate where you are missing this resolver? I assume you are referring to the

reviews

field on the

Experience

type

What I mean is that the

Experience

type has been re-defined (not imported) in the API layer, but the resolvers for it don’t seem to have been. In my previous projects, just using Apollo, if a field returns an array of another type, I’d have to tell it how to retrieve that data...

yes, you are right. For example, there is no

experiences

query in the application schema.

@nilan Ahhhh I’ve got the bit I’m missing. Your queries are adding JOINs aren’t they? Based on the

info

parameter that’s passed through. So in effect when asking for the

reviews

field, you don’t need a resolver because the array and fields are all already there.

yup, you can say it like that 🙂