Skip to content

Instantly share code, notes, and snippets.

Last active January 16, 2019 17:54
What would you like to do?
Outside-in type directed GraphQL

In the context of a fullstack web application here is the workflow I'd like to have for a great DX.

1. Client-side

1.1 Start from the UI, build it screen by screen in isolation with something like storybook/react-cosmos.

1.2 For a screen, write your data needs in term of graphql queries, mutations and/or subscriptions.

1.3 If you use a strongly typed language (like Purescript or Reason) it should be able to fail at compile time because schema's types are missing. For JS, the tools (cli, vscode extension...) should be able to point the undefined types, queries, mutations and subscriptions (if you use SDL in gql tag for example).

1.4 It's now time to write the schema to make your queries, mutations and subscriptions compile! You can define it with your strongly typed language of choice, or with graphql SDL. The point is to make your undefined types errors disappear.

1.5 At this point, you should be able to use tools to fake/mock your data out of your schema's types. You can now finish your screen in total isolation.

As a bonus, we should have tools to detect unused types, queries, mutations and subscriptions from our schema to always keep it as small as possible according to our UI needs.

Now that you designed a schema reflecting perfectly your UI data needs, we can start implementing the server!

2. Server-side

2.1 From the schema, we should be able to generate empty resolvers boilerplate. Or maybe we could use the schema defined with a strongly typed language to already have our resolvers types signatures.

2.2 Implement the resolvers using whatever you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment