Ben Kraft 8815d0991c Big refactor to separate operation-traversal from code-generation (#51)
## Summary:
I've felt for a while that types.go is way too confusing, and as I
started to implement some of the more complex cases of generating
interface-types, the cracks were really starting to show.  Luckily, I
also finally realized how to fix it: we need to separate the process of
traversing the GraphQL operation and schema to decide what types to
generate from the process of actually generating those types.  This
requires an extra set of intermediate data structures, but I think it
makes things quite a lot easier to understand -- and, importantly, it
means that the code-generation doesn't need to go in the order we
traverse the query/schema.

So in this commit, I did that huge refactor.  It's probably best to just
review types.go and traverse.go as if they were new; the old code was
quite hard to understand and the new code will hopefully make a lot more
sense.  (And to that end, review comments about what could be organized
better or needs more documentation are very much in order, even for code
that is mostly unchanged.)

This does introduce one bug, sort of, which is that rather than
generating broken code for list-of-interface fields, we generate no code
at all.  (A TODO in unmarshal.go describes why.)  I'll fix this when I
add support for those fields.  (It's all behind the AllowBrokenFeatures
flag, anyway.)  Otherwise, the only changes to generated code are that a
few methods are ordered differently, because we now generate the
implements-interface methods with the interface, rather than the
implementations, as it's much simpler that way.  (In GraphQL, unlike Go,
we know the list of all possible implementations of each interface, so
this is possible.)

## Test plan:
golangci-lint run ./... && go test ./...

Author: benjaminjkraft

Reviewers: dnerdy, benjaminjkraft, aberkan, csilvers, MiguelCastillo

Required Reviewers: 

Approved by: dnerdy

Checks:  Lint,  Test (1.17),  Test (1.16),  Test (1.15),  Test (1.14),  Test (1.13),  Test (1.17),  Test (1.16),  Test (1.15),  Test (1.14),  Test (1.13),  Lint

Pull request URL: https://github.com/Khan/genqlient/pull/51
2021-08-25 11:49:30 -07:00
2021-08-20 10:39:12 -07:00
2021-08-20 10:39:12 -07:00
2021-03-30 13:26:43 -07:00
2021-03-30 13:23:16 -07:00
2021-03-30 12:41:37 -07:00
2021-08-20 10:39:12 -07:00
2021-08-24 10:20:59 -07:00

generated graphql client ⇒ genqlient

genqlient: a truly type-safe Go GraphQL client

This is a proof-of-concept of using code-generation to create a truly type-safe GraphQL client in Go. It is certainly not ready for production use nor for contributions (see below).

Why another GraphQL client?

To understand the issue, consider the example from the documentation of shurcooL/graphql:

// to send a query `{ me { name } }`:
var query struct {
	Me struct {
		Name graphql.String
	}
}
// error handling omitted for brevity
client.Query(context.Background(), &query, nil)
fmt.Println(query.Me.Name)
// Output: Luke Skywalker

While this code may seem type-safe, and at the Go level it is, there's nothing to check that the schema looks like you expect it to. In fact, perhaps here we're querying the GitHub API, in which the field is called viewer, not me, so this query will fail. More common than misusing the name of the field is mis-capitalizing it, since Go and GraphQL have somewhat different conventions there. And even if you get it right, it adds up to a lot of handwritten boilerplate! And that's the best case; other clients, such as machinebox/graphql, have even fewer guardrails to help you make the right query and use the result correctly. This isn't a big deal in a small application, but for serious production-grade tools it's not ideal.

These problems should be entirely avoidable: GraphQL and Go are both typed languages; and GraphQL servers expose their schema in a standard, machine-readable format. We should be able to simply write a query { viewer { name } }, have that automatically validated against the schema and turned into a Go struct which we can use in our code. In fact, there's already good prior art to do this sort of thing: 99designs/gqlgen is a popular server library that generates types, and Apollo has a codegen tool to generate similar client-types for several other languages. (See DESIGN.md for more prior art.)

This is a GraphQL client that does the same sort of thing: you specify the query, and it generates type-safe helpers that make your query.

Usage

Example

To use genqlient, put your GraphQL schema (in SDL format) in a file schema.graphql, and put a query like the following in queries.graphql:

# queries.graphql
query getViewer {
  viewer {
    name
  }
}

Then run genqlient (go run github.com/Khan/genqlient), and it will generate:

// generated.go (auto-generated):
type getViewerResponse struct { ... }
func getViewer(ctx context.Context, client *graphql.Client) (*getViewerResponse, error) { ... }

Finally, write your code to call genqlient, like so:

// your code (error handling omitted for brevity)
graphqlClient := graphql.NewClient("https://example.com/graphql", nil)
viewerResp, _ := getViewer(context.Background(), graphqlClient)
fmt.Println("you are", viewerResp.Viewer.MyName)

//go:generate go run github.com/Khan/genqlient

For a complete working example, see example/. For configuration options, see go doc github.com/Khan/genqlient/generate.Config.

Documentation for generated code

For each GraphQL operation (query or mutation), genqlient generates a Go function with the exact same name, which accepts:

  • a context.Context (unless configured otherwise)
  • a genqlient/graphql.Client (you might have a global one, or init it inline)
  • arguments corresponding to the query arguments

It returns a pointer to a struct representing the query-result, and an error. The struct will always be initialized (never nil), even on error. The error may be a github.com/vektah/gqlparser/v2/gqlerror.List, if it was a GraphQL-level error (in this case the returned struct may still contain useful data, if the API returns data even on error), or may be another error if, for example, the whole HTTP request failed (in which case the struct is unlikely to contain useful data). If the GraphQL operation has a comment immediately above it, that comment text will be used as the GoDoc for the generated function.

The generated code may be customized using a directive-like syntax, # @genqlient(...). For full documentation of options, see go doc github.com/Khan/genqlient/generate.GenqlientDirective.

TODO: consider inlining the direct stuff; and document generated types further.

Development

genqlient is not yet accepting contributions. The library is still in a very rough state, so while we intend to accept contributions in the future, we're not ready for them just yet. Please contact us (via an issue or email) if you are interested in helping out, but please be aware the answer may be that we aren't ready for your help yet, even if such help will be greatly useful once we are! We'll be ready for the rest of the world soon.

Khan Academy is a non-profit organization with a mission to provide a free, world-class education to anyone, anywhere. If you're looking for other ways to help us, You can help us in that mission by donating or looking at career opportunities.

Tests

To run tests and lint, make check. (GitHub Actions also runs them.)

Notes for contributors:

  • Most of the tests are snapshot-based; see generate/generate_test.go. All new code-generation logic should be snapshot-tested. Some code additionally has standalone unit tests, when convenient.
  • Integration tests run against a gqlgen server in internal/integration/integration_test.go, and should cover everything that snapshot tests can't, including the GraphQL client code and JSON marshaling.
  • If GITHUB_TOKEN is available in the environment, it also checks that the example returns the expected output when run against the real API. This is configured automatically in GitHub Actions, but you can also use a personal access token with no scopes. There's no need for this to cover anything in particular; it's just to make sure the example in fact works.

Design

See DESIGN.md for documentation of major design decisions in this library.

S
Description
No description provided
Readme MIT 1.5 MiB
Languages
Go 92.3%
Go Template 7.6%
Makefile 0.1%