Finds fields by configurable struct tag

[codyleyhan]

Adds the ability to bind fields for resolvers based on gated struct tag that is provided in the gqlgen.yml file.

The binding now occurs in the following order when a struct tag is passed:

1. Struct Tag
2. Field name in embedded struct/ Actual field name

Also errors when struct tags would cause ambiguous binding such as two tags having the same value.

I have:

• Added tests covering the bug / feature (see testing)
• Updated any relevant documentation (see docs)

[vektah]

This is a bit magical, why json and not graphql or gqlgen?

#212 doesn't really explain this use case though, this seems to be the reverse (binding not generating models).

fieldName in the yaml allows for binding to differently named fields

[codyleyhan]

I used json because it seemed the most natural since graphQL uses JSON as the serialization format, binding on tags was a use case that I thought could be useful as there are some cases where graphQL is not the only view layer being used such as having a JSONAPI and graphQL at the same time which would mean writing json:"field" gqlgen:"field". If you think this would be a good feature I would be happy to work on it more to make it configurable/opt out.

[vektah]

Priority is a bit weird here too, consider

struct Thing {
    Bar string `json: "foo"`
    Foo string `json: "bar"`
}

which should be used?

Also, what should happen to

struct Thing {
    A string `json: "foo"`
    B string `json: "foo"`
}

[codyleyhan]

The current priority is that tags take least priority, this is a departure from how JSON encoding works now, I think it would be better to follow the std lib and the tags would have higher precedence over struct field names. I would consider the second case I bug and maybe some check could be added for this case?

[vektah]

The current priority is that tags take least priority,

That's not quite true, because they currently take priority at a field level (its happening in the same loop)

For the first example,
Bar != foo, but json:"foo" == foo so bind foo to Thing.Bar, even though there is a real field called Foo.

I think I'm open to this, if its gated behind some opt in config for which key to use. Also needs some tests.

[theoks]

@codyleyhan Could you post a small example showing a possible use case of this feature?