graphql-faker: Due to how extend works we can't replace type fields

So I was given this project a first try since I’m building some sort of boilerplate. I already have a schema, with (most) resolvers in place and I wanted to extend this with mock data. I’m assuming this scenario is probably not the goal for this project, but certainly seems like it can be used for it, and yet it can’t. I can’t replace fields within the existing types since extendSchema from graphqljs seems to complain. In this case what I’d like is to leave the schema as is, but replace the resolver instead.

Example: Original schema:

type User {
  id: ID!
  firstName: String
  lastName: String
}

Our fake schema in extend mode:

extend type User {
  firstName: String @fake(type: firstName)
  lastName: String @fake(type: lastName)
}

I would have expected the above syntax to work, and the resolver within it to return me the fake fields. I feel like I’m missing something obvious but if this isn’t supported I think it should. I’d be able to help if you can point me in the right direction.

EDIT: I’ve done something like this in the past with addMockFunctionsToSchema from graphql-tools but obviously, that one lacks the Faker integration, and it’s also hard to do proper relay connections in there. Maybe we could find a way to use it here as a last resort, but I think custom resolvers after leaving the schema in place should be the way to go.

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 9
Comments: 18 (5 by maintainers)

Most upvoted comments

@ahmedlhanafy Not ATM, it’s just a proposed solution. I will try to find time to implement it this month

+16

IvanGoncharov on May 6, 2019

I made NPM module based on my PR which enables fields overriding. If you need this feature in main module, you can subscribe to my PR’s notifications and use my fork-module until it gets merged.

https://www.npmjs.com/package/@proscom/graphql-faker

+12

hotsezus on Mar 15, 2021

just to use the proxy mode where some data are coming from actual API and some are mocked locally

That’s what I want!

# Remote schema
type User {
  username: String!
}

# Local schema
extend type User {
  # ...some more fields...
  username: String! @fake(type: username)
}

Sounds like @override would work for my use case but I am not sure why I even need to manually specify that—if it’s in the local schema, just override it instead of throwing an error?!

mxstbr on Apr 30, 2019

@mxstbr Do you want to mock the entire GraphQL API or just to use the proxy mode where some data are coming from actual API and some are mocked locally?

How about @override directive, e.g.:

extend type Post {
  acticle: String! @override @fake(type: lorem, options: {loremSize: paragraphs})
}

Will it work in your use case?

IvanGoncharov on Apr 30, 2019

This is unfortunately a deal-breaker for us, I would love to use this package but not being able to return mock data for existing fields is very annoying. Is there any workaround for this nowadays?

mxstbr on Apr 30, 2019

just override it instead of throwing an error?!

@mxstbr In this case, we are changing the behavior of extend as defined in GraphQL specification and implemented in any other GraphQL tool/lib. So I don’t want to enable this functionality by default. How about using --override CLI Flag instead of individually marking fields?

IvanGoncharov on Apr 30, 2019

@IvanGoncharov would like to check if you will have time to look at this any soon. Thx

rostislav-simonik on Oct 11, 2020