convert a graphql schema to a typescript definition

[bkinsey808]

I think it would be super cool to somehow automatically convert graphql schema to typescript definitions.

Something like this maybe?

https://github.com/avantcredit/gql2ts

[helfer]

Yeah, I think that's a great idea, more something for the client though. You have to be careful to create typescript definitions for query results, and not definitions for the whole schema, because GraphQL results don't actually have all the fields that the schema has!

Something to keep in mind if you want to take a stab at it. If you give it a try, let us know how it goes.

[helfer]

@bkinsey808 Are you still interested in pursuing this?

[bkinsey808]

to be honest I'm not really sure how to proceed.

[helfer]

I don't actually know either, but for a start, you could probably ask the person who wrote gql2ts how you might go about something like that. If you're using it on the client, you need to create types based on the query (given the schema, of course), which is different from what he is doing now. I don't know if it's possible to build that into the compiler, but even if you had to generate the types with an automatic build script before you can use them, that might already be useful.

[helfer]

On further investigation, it seems that overloads could be relevant to this question, because what you want to do is have a different return type based on which query you passed to the watchQuery or query function in Apollo Client, or runQuery on Apollo Server (after the refactoring I'm currently doing). Does that make sense?

[stubailo]

@martijnwalraven is working on a code generator that might be able to address this use case!

[bkinsey808]

@helfer yes, that makes sense. But for overloads to work, if I understand correctly, the input parameter for query or watchQuery would have to be specifically typed.

[stubailo]

Yeah I think you would basically need to code generate a type for each query and fragment.

[bkinsey808]

Ideally, I'd like it if interfaces could be generated from the schema at point of compile, named in a standard way, and the client could import them in a standard way.

[helfer]

The issue with generating the types from the schema directly is that GraphQL allows you to ask for only a subset of the fields on that type. So it might look like your code is type-checked, but it's actually not. That's why types have to be generated based on fragments or queries.

[bkinsey808]

Having to generate types per query seems like a real drag. Is it even possible if the queries are generated dynamically? Seems like a perfect use case for nullable types, no? If I understand correctly, by using nullable types, it doesn't matter what subset of fields are chosen from the schema.

[helfer]

@bkinsey808 You can't have type checking at compile time and dynamic queries. You have to pick one or the other.

Nullable means the field is null. That's different from it not being there at all, which is what GraphQL queries are all about.

Since this issue isn't really related to apollo-server, but graphql-js in general, I feel like maybe you should open the issue on that repo. That would also make it more likely that other people who are interested in it will find it.

[bkinsey808]

Ok, not nullable, how about Undefineable?

microsoft/TypeScript#7426

[nevir]

If you guys are interested, I'm also working on a converter that approaches this from the opposite direction: https://github.com/convoyinc/ts2gql

[stubailo]

That's quite interesting! Curious how you will end up using that.

[nevir]

We've got a pretty hefty hierarchy of typescript definitions for our various resources already; it's working quite well so far to consume those interfaces (and a new one that describes the GraphQL root query).

The output is then piped into apollo-server:

export default buildSchemaFromTypeDefinitions([
  fs.readFileSync('path/to/schema.gql', {encoding: 'UTF-8'}),
  `
    schema {
      query: RootQuery
    }
  `,
  // And eventually any other special cases we may want to include
]);

I suppose I could have gone straight to the underlying GraphQL object model, but this is certainly more inspectable :P

[stubailo]

Sounds good to me! Pretty exciting :] I'd love to see a code sample or blog post about this at some point!

[helfer]

Closing this issue for now, since it's been inactive for a while.

[igl]

Typescript 2.1's keyof operator comes in to the rescue.
Very interesting feature that could enable creating sub-types of a bigger schema type without preprocessing the code. See:

https://blogs.msdn.microsoft.com/typescript/2016/12/07/announcing-typescript-2-1/

[vangorra]

Here's an incredible rudimentary script we run. It will convert our schema file to typescript defs.

https://gist.github.com/vangorra/cd75c27805aafd3c070fdcc8c3bc496b

[stubailo]

Apollo Codegen now supports TypeScript and soon Flow: https://github.com/apollostack/apollo-codegen

Note that if you are using this for client-side type generation the best way is to generate specific types for every query, so that you can ensure your queries have loaded all of the fields you need for your UI.

[DxCx]

also i came across http://graphql-codegen.com which works very good in my experiance, used it to build typings for schema in compile type, while resolvers are using this typings so if scheme has breaking change, it will pop right up on compilation :)

[damiangreen]

http://graphql-codegen.com/ no longer exists

[BramKaashoek]

I wrote https://www.npmjs.com/package/typescript-typedefs for this purpose.