Generalize transport using an interface

[F21]

The current implementation supports using a http.Client. As discussed in #1, it would be nice if there is a transport interface, so that users of the package can implement their own transport.

In my case, I am using graphql over GRPC. GRPC is built on top of http.Client and the http.Client is not used directly. Instead, the a GRPC connection is passed to the generated GRPC client. For a simple example see: https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_client/main.go

I'd imagine that the interface should be quite low level and "close to the wire". In other words, transports should not have to know too much about how graphql works.

[dmitshur]

Thanks, I'll definitely consider this. First, I'd like to understand it better.

In my case, I am using graphql over GRPC.

Can you elaborate on how you do that?

Also, are you interested in this for general GraphQL uses, or for GitHub GraphLQ API v4 as well? As far as I know, they only allow access over HTTP at this time.

[F21]

Currently, I am interested in using this as a general GraphQL client.

In my case, I am using neelance/graphql-go to implement my GraphQL servers.

I have a tiny package that uses modified generated GRPC code. My GRPC client is very simple: It has a Query method that takes a query, variables and an operationName. This is then serialized as JSON and sent over GRPC to the server. The GRPC server on the server side also only contains 1 method that unmarshals the JSON to get the query, variables and operationName, which it then executes using my server implemented using neelance/graphql-go.

It might seem weird that I am doing this over GRPC when HTTP would work, but GRPC provides a lot of useful features out of the box over HTTP and has a great ecosystem around it

For example:

• It has built in support for backoff strategies, so that we can implement a built-in circuit breaker directly in the client if desired: backoff: allow configuration of backoff strategy grpc/grpc-go#601
• Great ecosystem that is pretty much plug and play: https://github.com/grpc-ecosystem
• Some of my favorites are:
  • Opentracing to trace a request through multiple microservices
  • Prometheus to automatically collect GRPC client/server metrics
  • Probably a lot more things I am not aware of yet

[dmitshur]

@F21, some updates here.

First, I've factored out the general GraphQL client into a separate package https://github.com/shurcooL/graphql. So this issue belongs there now.

Second, you said originally:

it would be nice if there is a transport interface, so that users of the package can implement their own transport. [...] I'd imagine that the interface should be quite low level and "close to the wire". In other words, transports should not have to know too much about how graphql works.

Can you tell me more about what you'd want the interface to look like. Would it be something like this?

type Doer interface {
    Do(req *http.Request) (*http.Response, error)
}

We've used that at https://godoc.org/github.com/tambet/go-asana/asana#Doer.

Finally, do you still need this?

[F21]

@shurcooL The GraphQL package looks great!

I have decided not use GraphQL over GRPC. In terms of the interface, my original thoughts were to provide something more generalized, for example, request and response structs within the graphql package. For example, someone might not want to use http, but build their own layer on top of TCP.

Having said that, I don't really need this anymore, so maybe we should close this issue and open a new one when the need arises in the future?

[dmitshur]

I see.

Having said that, I don't really need this anymore, so maybe we should close this issue and open a new one when the need arises in the future?

That sounds like the best way to proceed, let's do that. Thanks!

[dmitshur]

my original thoughts were to provide something more generalized, for example, request and response structs within the graphql package. For example, someone might not want to use http, but build their own layer on top of TCP.

As far as I know, GraphQL protocol is usually implemented on top of HTTP. It uses HTTP methods like GET and POST. I suppose if you control both the server and client, you could use something different. In any case, there's no need to investigate this further until someone has a concrete need.