If an object implements an interface the user shouldn't have to explicitly add the interface fields to the object. Currently, the implementation mandates this:

interface Iterator {
  next: String
}

type Sentence implements Iterator {
  # next field must be specified
  next: String

  # Now Sentence specific fields
  verbs: [String]
}

The desired usage would look like this:

interface Iterator {
  next: String
}

type Sentence implements Iterator {
  # next field is implied
  # Thus, you can just have sentence specific fields
  verbs: [String]
}

The type converter only converts one type at a time and doesn’t check to see if the read slice could happen more. It should still convert one type at a time but it should continue converting till it overflows the given read slice or fills it perfectly.

This will both maximize the convert buffer usage and the cases where ioutil.ReadAll is used on the converter since it uses a large read slice.

Currently, when a non-null type is converted from JSON to IDL it is rendered as a list type i.e. [] instead of !.

Once running services are included as a source of input, one nice feature would be to generate their IDL file if they don't already have one. An example usage would look like: gqlc --schema_out . https://api.example.com/graphql. This would generate a IDL file called schema.gql.

Many services require an auth token within the request header. Thus, it is necessary to support at least an auth header flag option when import/fetching types from a remote service.

Two great motivators for this are the Github and Gitlab APIs. Both require bearer tokens in the auth header.

Currently, it's nearly impossible to track from which commit a dev version of the compiler was built. It would be great if the commit prefix could added to dev version like:
gqlc version gqlcD.E.V-fe193b1 linux/amd64.

Only one challenge with this: How to get commit prefix without introducing more build steps i.e. go build should still be all it takes to build a dev version of the compiler from any branch.

Currently, the default value for any enum is just a then enum value stringified. What would be better is a custom directive that would allow a user to provide a value for the enum

Don't navigate directly to the guide. First, provide a simple homepage to quickly introduce gqlc and some of its features/use cases.

WIP:

• Fix codecov upload problem
• Add release workflow for tags

To shrink binary size strip debug symbols by passing -ldflag="-s -w"

Giving a relative path to --go_out doesn't work. It just always generates the file in the current working directory

A nice CI job(s) would be testing that the generated code compiles at least and possibly provide default resolvers so an e2e test of each runtime could be performed.

I have a suggestion for the code generator w.r.t resolve functions that survive regeneration.

Given the currently generated code:

var MutationType = graphql.NewObject(graphql.ObjectConfig{
	Name: "Mutation",
	Fields: graphql.Fields{
		"createQuotation": &graphql.Field{
			Type: graphql.NewNonNull(QuotationType),
			Args: graphql.FieldConfigArgument{
				"input": &graphql.ArgumentConfig{
					Type: CreateQuotationInputType,
				},
			},
			Resolve: func(p graphql.ResolveParams) (interface{}, error) { return nil, nil }, // TODO
		},

When the Resolve: snippet is replaced to:

var MutationType = graphql.NewObject(graphql.ObjectConfig{
	Name: "Mutation",
	Fields: graphql.Fields{
		"createQuotation": &graphql.Field{
			Type: graphql.NewNonNull(QuotationType),
			Args: graphql.FieldConfigArgument{
				"input": &graphql.ArgumentConfig{
					Type: CreateQuotationInputType,
				},
			},
			Resolve: resolveMutationCreateQuotation
		},

Then we could have a separate Go source file for each definition which only gets generated if there is no such file.

resolveMutationCreateQuotation.go

func resolveMutationCreateQuotationp graphql.ResolveParams) (interface{}, error) { 
     return nil, nil // TODO 
}

Is your feature request related to a problem? Please describe.
Can't generate Dart code

Describe the solution you'd like
Generation of Dart code

When a enum value is used as a default value the generated code is incorrect. The Enum name either has to be a string or instead the value given to @as(value: String) needs to be used instead.

This issue is a placeholder for community voting on whether Java should be support by gqlc. If you're in favor of adding a Java generator to gqlc then comment with a +1.

Given

type A {
    id: ID! 
}

type B {
    id: ID! 
}

type C {
    id: ID! 
}

union U =
    A
    | B
    | C

type Mutation {
    foo : U!
}

and compiling this will generate

... stuff deleted ...

var UType = graphql.NewUnion(graphql.UnionConfig{
	Name: "U",
	Types: []*graphql.Object{
		AType,
		BType,
		CType,
	},
	ResolveType: func(p graphql.ResolveParams) *graphql.Object { return nil }, // TODO
})

which has an incorrect definition for ResolveType.
It must be:

ResolveType: func(p graphql.ResolveTypeParams) *graphql.Object { return nil }, // TODO

Description

It would be cool/useful if you import types from an existing service. This could be especially useful for early adoption since most developers don't necessarily write their entire schemas in the GraphQL IDL.

Implementation

Since gqlc already supports remote file importing just one extra step needs to be added. If the endpoint isn't a file send an introspection query for all of its types. An optimization could be included to check if the endpoint ends with /graphql since this is a common naming practice for a GraphQL endpoint.

The guide will be a brief walk through of all the features gqlc has to offer

An issue arises when you remove things from your .gql source and then try to regenerate your code. The old generated file isn't fully cleared which leads to garbling of text.

These may be better in gqlc/graphql or gqlc/compiler but more investigating is required to determine where this should really be used.

Is your feature request related to a problem? Please describe.
Currently, in order to process a remote file you have to download it locally and then pass it to gqlc. This isn't necessary since most use cases of the *.gql files will only be for gqlc and no other tool. Thus, gqlc should just be able to read them directly into memory from a remote location.

Describe the solution you'd like
If a filepath is remote, then fetch it and wrap it in a io.Reader

Describe alternatives you've considered
Downloading myself then processing *.gql files locally

This route will be for documenting both gqlc and community maintained plugins. It will also provide a walkthrough for implementing a plugin.

Is your feature request related to a problem? Please describe.
Can't generate Go code

Describe the solution you'd like
Generation of Go code

Currently, type signature quering only goes one level deep i.e. [String] works but [String!] doesn't work.

Currently, the @resolver directive only applies to FieldDefinition which is fine for objects but not for unions, enums, etc.

Is your feature request related to a problem? Please describe.
Can't generate Javascript code

Describe the solution you'd like
Generation of Javascript code

Describe the bug
Currently, if a request is made to a running service that requires authentication (a.k.a. Authorization header) the body is still tried to be read and an unexpected io.EOF is returned by something.

To Reproduce

gqlc --doc_out . https://api.github.com/graphql # Githubs' API requires a Personal Access Token

Expected behavior
The "unathorized/bad request" response should be converted into an error which can be passed up the call stack making it much easier for the user to see exactly what went wrong. A suggestion message could also be logged saying something like: It seems you forgot to provide an Authorization header. This can be done by, gqlc -H "Authorization=Bearer your_token".

Document all standard generators.

https://github.com/yuin/goldmark

A possible alternative to having users write plugins would be to implement a generator that uses a simple text/template. An example of this approach already in existence is the GraphQL Code Generator.

Given the schema

type Query {
    foo : Boolean!
}

extend type Query {
    bar : Boolean!
}

the compiler + golang generator produce

package main

import "github.com/graphql-go/graphql"

var QueryType = graphql.NewObject(graphql.ObjectConfig{
	Name: "Query",
	Fields: graphql.Fields{
		"foo": &graphql.Field{
			Type: graphql.NewNonNull(graphql.Boolean),
			Resolve: func(p graphql.ResolveParams) (interface{}, error) { return nil, nil }, // TODO
		},
	},
})

in which the Field "bar" is missing but expected.

Currently, builtin directives such as resolver are being kept in the documentation. They should be stripped out of the ast.Document before documentation is generated. This allows for cleaner documentation.

Since a sub command has been added, cobra checks the arguments as if they are a sub cmd name. The solution is simply set the field Args: cobra.MinimumNArgs(1) in the root cmd.

After some playing around with Github GraphQL API endpoint, the current client timeout isn't sufficient enough for most requests. Thus two routes can be chosen:

1. Increase the timeout
2. Add retrying logic with backoff

In my opinion, the retry with backoff is the better solution than just arbitrarily increasing the client timeout.

Is your feature request related to a problem? Please describe.
Implement GraphQL document type checking

Describe the solution you'd like
Identify unimplemented types.

I'm personally a fan of the go version output so I'd like to mimic that for gqlc.

In the type converter, type/field description are not properly quoted.

Currently, I am using part of the files generated by github.com/99designs/gqlgen w.r.t the models.

I propose to have a generator option that will also generate the structs for all the types and inputs defined in the schema.

The README still references a few pre-refactoring things which no longer exist or make sense.

All builtin GraphQL runtime types should be ignored since they are defined in the spec. These include Int, Float, String, @skip, @deprecated, etc.

Any internal types should also be ignored a.k.a the introspection types: __Type, __Field, etc.

Is your feature request related to a problem? Please describe.
Like protoc, gqlc should support passing options to generators.

Describe the solution you'd like
Add option flag arg to compiler.RegisterGenerator() signature

Describe alternatives you've considered
Auto create option flag based on generator flag name (possibly trim "--" and "_out" from flag name to get generator name)

Add a flag, verbose, to log what going on.

consider the following example

type Permissions {
    shoppingCart: Boolean!
}

extend type Query {
    permissions: Permissions!
}

type Query

The compiler sees an extension on Query and fails immediately because it is defined later in the file. Such a file is created because we concatenate multiple files into one before using gqlc.

I think the compiler should use a two-phase method in resolving types and definitions ; first read all definitions then verify type completeness.

Currently, in the help/usage text there is no mention of the version subcommand

Currently, if there is a default value that is an enum value it will be printed as a string, which is incorrect.