Proposal: Generating methods for accessing interface fields

[ianling]

Current behavior

Today, when gqlgen processes the following schema:

interface Animal {
    species: String!
}

type Human implements Animal {
    species: String!
    name: String!
}

type Dog implements Animal {
    species: String!
    breed: String!
}

It produces the following Go:

type Animal interface {
	IsAnimal()
}

type Human struct {
	Species string `json:"species"`
	Name    string `json:"name"`
}

func (Human) IsAnimal() {}

type Dog struct {
	Species string `json:"species"`
	Breed    string `json:"breed"`
}

func (Dog) IsAnimal() {}

This approach isn't conducive to actually using the Animal interface in your own Go code. For example, I can't access the <Animal>.Species field in a function that accepts an Animal as a parameter:

func GetSpecies(a Animal) string {
    return a.Species // does not compile!
}

Proposed behavior

The schema above could instead produce the following Go:

type Animal interface {
	IsAnimal()
        Species() string // <---- new method in the interface that exposes the Species field
}

type Human struct {
	species string // <---- notice the interface field is unexported
	Name    string `json:"name"` // <---- non-interface fields specific to this struct remain exported
}

func (Human) IsAnimal() {}

func (model Human) Species() string {return model.species}

type Dog struct {
	species string
	Breed    string `json:"breed"`
}

func (Dog) IsAnimal() {}

func (model Dog) Species() string {return model.species}

This allows access to the interface's fields via the method:

func GetSpecies(a Animal) string {
    return a.Species()
}

This would obviously be a breaking change that would need to be opted into via a config option.

One potential problem that needs some discussion is setter methods (since getters are already covered above), as well as constructors for setting unexported fields. Alternatively, the fields could remain exported, but we could simply add GetSpecies() (for example) methods for interface fields, so that the names wouldn't conflict (GetSpecies() vs Species).

[giautm]

the JSON tags don't work on the private field.

species string `json:"species"`

How about this?

func GetSpecies(a Animal) string {
	switch t := a.(type) {
	case Dog:
		return t.Species
	case Human:
		return t.Species
	}
	panic("Unknow type")
}

[ianling]

Woops, I missed one of the JSON tags, thanks.

Your solution works fine for my example, but it starts getting cumbersome if you have 10+ things implementing the interface. It also doesn't work if you are writing a library that contains an interface other developers will implement themselves.

[giautm]

but it starts getting cumbersome if you have 10+ things implementing the interface.

I will use codegen for this part, so the number of things is not a problem for me.

It also doesn't work if you are writing a library that contains an interface other developers will implement themselves.

Please provide your use case, and make sure the maintainer team of GQLGen agrees with that before you put too much effort into it.

[ianling]

I implemented this in this PR #2218

I do not have a solution in place for a constructor, it only has getter/setter methods for the interface fields.

[ianling]

I wonder if a better solution would be to generate a normal struct from a GraphQL interface and embed that struct into generated structs.

type Animal struct {
	Species string `json:"species"`
}

type Human struct {
	Animal
	Name    string `json:"name"`
}

type Dog struct {
	Animal
	Breed    string `json:"breed"`
}

Interfaces in Go are generally meant for defining behavior, not fields/data. Interfaces in GraphQL are the opposite and are more akin to the usage of embedded structs. This solution also avoids the issue of unexported fields.

[ianling]

Closed the previous PR in favor of this one #2220 that uses embedded structs instead of Go interfaces.