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

[IvanGoncharov]

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

[hotsezus]

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

[mxstbr]

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]

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?

[IvanGoncharov]

@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]

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?

[rostislav-simonik]

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

[IvanGoncharov]

@blackxored I want this tool to be compliant with GraphQL spec and graphql-js so I can't change how extendSchema works. We also design extend mode to be used for applying non-breaking changes to existing GraphQL API and your use case is really different from that.

Hower, I have an idea how to accommodate your use case without introducing too much complexity into graphql-faker. In source code we have fakeSchema function that accepts schema and attaches resolvers to it. I can expose it as an NPM package so you would be able to write:

import { fakeSchema } from 'graphql-faker';
import { makeExecutableSchema } from 'graphql-tools';
const typeDefs = `
  type User {
    id: ID!
    firstName: String @fake(type: firstName)
    lastName: String @fake(type: firstName)
  }
`;
const resolvers = {
  User: {
     id() {
        // ...
     }
  }
};
const executableSchema = makeExecutableSchema({
  typeDefs,
  resolvers,
});

// Assing missing resolvers
fakeSchema(executableSchema);

// Pass executableSchema to your server

Will it solve your use case?

[liuchong]

Seems we need to keep multiple version of schema in this case, maybe we could added a "patcher" function.

In fact, I've just defined another fake version of the exact same type and append it onto the end of the original schema, and it works...like:

type Post {
  id: ID!
  article: String!
}

type Post {
  id: ID! @fake(type: uuid)
  article: String! @fake(type: lorem, options: {loremSize: paragraphs})
}

by the way, I find this "fakeSchema" 👍 solves my issue: #32

[IvanGoncharov]

Seems we need to keep multiple version of schema in this case, maybe we could added a "patcher" function.

@liuchong All GraphQL tools (including graphql-tools) I'm aware of will silently ignore unknown directives, so you can safely use one schema.

by the way, I find this "fakeSchema" 👍 solves my issue: #32

Implementing it requires me to switch from custom fork of graphql-js to official version + a lot of refactoring. I plan to start working on v2.0.0 release next month.
I will ping you after initial refactoring is done so you could help with PR if you have time for it.

[liuchong]

@IvanGoncharov Great, thanks!

[mxstbr]

That sounds great to me!

[ahmedlhanafy]

@IvanGoncharov Are @override or --override available ATM?

[adaam2]

Maybe I'm misunderstanding significantly 😆 , but why would you want to define new fields via extend that don't exist in your original (remote) schema?

I would think that that main use case for this library is to mock existing schema field data?

👀

[steezeburger]

@adaam2
I'd like to use graphql-faker to mock the api for new features so the front end can implement a feature without all backend work being done. Sometimes new features require adding fields to existing types. For example, after creating a new Course type, I'd want to add a courses field to Contact:

type Course {
  id: ID! @fake(type: uuid)
  title: String @fake(type: word)
  description: String @fake(type: lorem)
}

extend type Contact {
  courses: [Course!] @listLength(min: 1, max: 1)
}

[adaam2]

@steezeburger fair enough, but i think there's a place for both use cases here :)

[orefalo]

Wouaou... this issue was open back in 2017 and there is still no solution?
It's a pretty common use case, judging by the people who interacted on this thread.

I am also looking at the @OverRide or { fakeSchema } solution -

Sincerely

[supaspoida]

This is exactly my use case as well. Have an existing GraphQL schema from a Hasura instance that I want to use to generate faked seed data to feed into mutations.