go-graphql

Go GraphQL

GraphQL moves query planning to the client. That is the feature and the danger: one innocuous query can become ten thousand database round trips, and one over-permissive field can leak another tenant's data. Both are solved at the server, not in the schema review.

1. Schema-First with gqlgen

The .graphql schema is the source of truth. gqlgen generates models, resolver stubs, and the execution layer from it.

go get -tool github.com/99designs/gqlgen
go tool gqlgen init      # once
go tool gqlgen generate  # after every schema change

# gqlgen.yml — bind generated types to your own models
models:
  User:
    model: github.com/myorg/app/internal/domain.User
  ID:
    model:
      - github.com/99designs/gqlgen/graphql.ID
      - github.com/99designs/gqlgen/graphql.Int64

Bind domain types explicitly. Left to itself gqlgen generates a parallel set of anaemic structs, and every resolver becomes a mapping function.

Commit generated code, and fail CI when it is stale:

go tool gqlgen generate && git diff --exit-code

Never edit generated.go or models_gen.go. resolver.go and the *.resolvers.go files are yours.

2. Resolvers Stay Thin

A resolver translates a GraphQL request into a service call. It contains no business logic and no SQL.

func (r *queryResolver) User(ctx context.Context, id string) (*domain.User, error) {
    u, err := r.users.Find(ctx, id)
    if errors.Is(err, domain.ErrNotFound) {
        return nil, nil // nullable field: absent, not an error
    }
    if err != nil {
        return nil, fmt.Errorf("find user %s: %w", id, err)
    }
    return u, nil
}

Inject dependencies through the Resolver struct, never through package globals:

type Resolver struct {
    users  UserService
    orders OrderService
    loader *Loaders
}

Always propagate ctx. It carries the request deadline, the authenticated principal, and the per-request dataloaders.

3. The N+1 Problem — the one that matters