Are you aware of another Go GraphQL client?

[dmitshur]

Hey @matryer!

I just discovered the existence of this Go GraphQL client via reddit.

I hope you don't mind this question, but I wanted to ask if https://github.com/shurcooL/graphql (and/or https://github.com/shurcooL/githubql) is on your radar already or not? It's an open source Go implementation of a GraphQL client. If you're interested, I can share some links with additional background information on its design and history, API design decisions and tradeoffs, etc.

Let me know if you're open to talking more about this and potentially working together to improve our projects. My goal is for Go users to have as nice a Go GraphQL client available to them as possible.

Thanks!

[matryer]

Yes, I did see it. I mostly liked it, except for the complication around using structs for requests. When I tried to use that I failed, and that's why I made one that just took strings for requests. Otherwise, I think they're pretty similar.

[dmitshur]

Yes, I did see it.

Good to hear!

except for the complication around using structs for requests. When I tried to use that I failed

I see, thanks for feedback. By any chance, do you remember what the query was? (It's np if not, of course.)

I'm considering making a GraphQL query -> Go code tool to make the conversion process easier.

[matryer]

Sorry I can’t share details about the query. The trouble is, the point of GraphQL from what I can tell is that you only ask for what you need at any time. This means that every query (probably) is going to be unique. So there’s not much use in building clients etc, that abstract it away. Otherwise, you might as well use REST and get every field for every item every time. Of course, this doesn’t nullify what you’re saying. A way to take a GraphQL query and generate the Go code would be nice, as long as it doesn’t add loads of structs or other types to your code (it could always do this inside function bodies so they don’t clog up the global space) it could be pretty cool.

…

On 11 Dec 2017, at 17:12, Dmitri Shuralyov ***@***.***> wrote: Yes, I did see it. Good to hear! except for the complication around using structs for requests. When I tried to use that I failed I see, thanks for feedback. By any chance, do you remember what the query was? (It's np if not, of course.) I'm considering making a GraphQL query -> Go code tool to make the conversion process easier. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGNG85dgcdPh48H1q8y0bN2sjZAE_qBks5s_WJlgaJpZM4Q8NEc>.

[dmitshur]

This means that every query (probably) is going to be unique.

I agree.

as long as it doesn’t add loads of structs or other types to your code (it could always do this inside function bodies so they don’t clog up the global space) it could be pretty cool.

My GraphQL queries usually involve writing a var q struct { ... } that defines the query. There's rarely a need to make global types for queries, other than to share common fragments that are used by many queries. As I understand, you need to provide a type/variable that's very similar in nature as 3rd parameter to Run.

To clarify what I meant by a "GraphQL query -> Go code tool", an example input to it would be a query like:

query {
	me {
		name
	}
}

And the generated Go struct for that would be:

var query struct {
	Me struct {
		Name string
	}
}

(No global types are involved.)

[matryer]

Yeah, honestly I don't hate it. The more complicated cases did start to look a bit too complicated though, with struct tags etc.