Bump to 1.0

[nknapp]

@msiegenthaler Do you think there are any more major features missing on the project?
Otherwise, I would go to 1.0.0 after fixing #30.

[msiegenthaler]

Basically the only thing I see missing is support for custom scalar types. I'm not really sure how to tackle those - as of now I think the best way would be to just render them to any.

Anyway, I agree we should release 1.0.0 after fixing #30. Adding support for custom scalars should not break the 'API', so we can add that in 1.1.0.

[Birowsky]

Hey, fellers! What's the hold up? This is the last package i need for a perfect server toolchain. And trust me, i've tried them all.

[nknapp]

I actually wanted to create some more docs, but then I got caught up in other projects.

If you need it, I can create 1.0.0 and update the docs later. The API should be stable already.

[Birowsky]

The problem that I have is with the GraphqlField type. In your renderer code, it's:

type GraphqlField<Args, Result, Ctx> = Result | Promise<Result> |
        ((args: Args, context: Ctx) => Result | Promise<Result>)

However, based on the graphql types, it looks different:

export type GraphQLFieldResolver<TSource, TContext> = (
    source: TSource,
    args: { [argName: string]: any },
    context: TContext,
    info: GraphQLResolveInfo
) => any;

Am I maybe missing something? I'm new to graphql.

[nknapp]

I don't know where the GraphQLFieldResolver comes from. Is that Apollo? The interfaces generated by this project are not for Apollo. They can be implemented by the root-value used in this example: http://graphql.org/graphql-js/#writing-code. Have a look at the usage example in the README

[Birowsky]

• Here is the GraphQLFieldResolver, and yes, my intention was to use your typewriter in Apollo project. But I didn't realize that it's made for the reference implementation.
• I already tried to make the types match that prescription. Let's see how it works out..

[nknapp]

Maybe there should be an option to generate Apollo code instead of the reference implementation. I could prepare the code to allow diffrent implementations. @msiegenthaler already thought about doing this.

[Birowsky]

You guys have my cheerleading support :}

[msiegenthaler]

sorry, I was on vacation

basically there are two ways to use graphql with apollo:

• default field resolver with a "smart" root object (what we are doing now)
• write (or generate) your own field resolvers

I got confused by this as well first. We could generate the field resolvers, but I think it's easier and more portable the way we're doing it now. I actually had the generation written, but then discarded it (there should be a commit for that in the history if you're curious).

I'm using it with apollo as well, do you have problems using it with it?

[Birowsky]

@msiegenthaler well, as I mentioned, the resolver types are incorrect. I already tried some naive approach, but the first problem that became apparent, is that the parent type is not JUST the parent entity from the graph, example a User {strength}, but it's actually User {strength, strengthId}. Because entities, as they come from the db, are not joined.. right? am I making myself clear? :}