Using GraphQL Faker

I've mentioned it a few times before and it's still true: I'm a big fan of GraphQL. The tooling around it has had some growing pains because it's still relatively new, but having such a large amount of control on the front-end allows you have a greater knowledge of the data you're querying, and it encourages you to write components hierarchies that more closely resemble the schema structure.

It seems pretty common to split back-end API development from front-end app work into two separate teams, but it's difficult for the front-end team to smoothly development UI components if the GraphQL endpoint doesn't have the new queries hooked up to resolvers to return live data.

The best-case scenario is for the front-end team to work on something else until the real data is ready, but that isn't always a decision the teams get to make and it isn't necessarily realistic. The next best thing is for the two teams to agree on an updated schema, or at least come to a rough idea of of the new types and queries. This "contract" between the two teams is likely to change in some ways, but it's enough for the front-end team to go on to generate some fake responses and continue development.

Fake the Schema

GraphQL Faker is build on top of faker.js and allows you to extend the schema of a GraphQL endpoint and return fake data generated using faker.js or a custom example. There are a lot of different types available, including names, emails, zip codes, and image URLs.

When starting the graphql-faker service, you have the option of extending a current endpoint by specifying the URL. This could either be from your dev environment, or the actual production endpoint (which means you'll have access to all your existing queries and types, and also be able to retrieve real data if it already exists). GraphQL Faker runs on port 9002 by default, and it allows you to edit the generated schema directly at localhost:9002/editor.

graphql-faker --open --extend http://localhost:5000/graphql

type User {
  id: ID @fake(type: uuid)
  email: String @fake(type: email)
  password: String @fake(type: password)
}

extend type Query {
  user(id: ID): User
}

We're extending the type Query because we have an existing schema we'd like to still be available. We now have a new user query available at the endpoint localhost:9002/graphql. Using something like the webpack-dev-server, we can redirect our GraphQL requests to the GraphQL Faker instance, or we could setup our own custom proxy on our server.

A Few Drawbacks

One main drawback I've run into is that you can't fake the response for an existing property. Let's imagine our User type already existed on the endpoint and we're extending it with GraphQL Faker.

extend type User {
  newProperty: String @examples(type: word)
}

extend type Query {
  user(id: ID): User
}

When we run our user query, we'll get our faked newProperty, but the values of the existing properties will be defaults for whatever GraphQL type they are (ID, String, etc.).

{
  "data": {
    "id": "VXNlcjoyODE3ODIyODQz",
    "email": "string",
    "password": "string",
    "newProperty": "candle"
  }
}

Another related issue is that the params we're using on our fake queries are essentially decoration because the response will be faked the same way regardless of what's provided. We can't use a parameter to specify the number of faked response items, or filter them in some way.

Summary

Overall, GraphQL Faker is a really nice tool for continuing work on UI components when the back-end schema isn't quite there. Making a GraphQL Faker instance the default endpoint for the development environment has had great results for one of the projects I'm currently working on. You should definitely check it out if the need arises.