Breaking out resolvers into packages

[bofia]

What happened?

When running gqlgen all the generated resolvers are in a single package. How would you organize a large project that has hundreds of different types? It seems like the package would have hundreds of files in the same directory.

What did you expect?

A way to organize large schemas. Federation might be a solution but would like to avoid that

Minimal graphql.schema and models to reproduce

versions

• gqlgen version? v0.11.3
• go version? 1.13.7
• dep or go modules? N/A

[qhenkart]

@bofia actually you don't need gqlgen to support this feature. You can easily do this with Golang's native type extension. With this, I have developed several unique query resolvers types, as well as delegated a separate package to handle mutations which also has unique mutation resolver types

First I will showcase how to use multiple types to organize your code, second I will show you how to use multiple packages.

In your main resolver.go file you will have type set like this

resolvers/resolver.go

type Resolver struct{}
type queryResolver struct{ *Resolver }

// Query returns the query resolver
func (r *Resolver) Query() generated.QueryResolver {
	return &queryResolver{r}
}

func (r *Resolver) User() generated.UserResolver {
	return &userResolver{r}
}

resolvers/users.go

_root resolvers must be a part of the queryResolver_
func (r *queryResolver) User(ctx context.Context, id string) (*models.User, error) {
  return nil, nil 
}

 _subresolvers of the root resolver can be a part of the sub class we've created_
type userResolver struct{ *Resolver }

func (r *userResolver) Posts (ctx context.Context) {*models.PostResponse, error} {
  return nil, nil
}

So that is a way to at least separate the types you are dealing with which makes testing and code organization much easier. However I did not yet answer your question about using different packages. Using different packages uses the exact same concept as above but we are delegating the class extension to another package. In this example, we are doing it for mutations

resolvers/resolver.go

type mutationResolver struct {
	*mutations.Resolver
}

// notice here we are calling a packageName.Resolver
func (r *Resolver) Mutation() generated.MutationResolver {
	return &mutationResolver{&mutations.Resolver{}}
}

/resolvers/mutations/mutations.go

package mutations

// Resolver defines the mutation resolver
type Resolver struct{}

func (r *Resolver) CreateUser(ctx context.Context, input models.CreateUserInput) (*models.User, error) {
    return nil, nil 
}

Using subclassing, you can easily organize your code into as many packages you want, and create any system that makes the most sense for your use case

[bofia]

@qhenkart Thanks for the pointer! I followed your mutation example, however when I run gqlgen generate, it will revert back to the one package assumption. E.g. a resolver/mutation.resolvers.go will get generated to look like this:

package resolver

func (r *mutationResolver) TestMutate(ctx context.Context, foo *string) (*string, error) {
	panic(fmt.Errorf("not implemented"))
}

// Mutation returns generated.MutationResolver implementation.
func (r *Resolver) Mutation() generated.MutationResolver { return &mutationResolver{r} }

type mutationResolver struct{ *Resolver }

even though I already implemented everything needed in resolver/resolver.go

[qhenkart]

@bofia would you mind sharing your gqlgen.yaml file? I'm not familiar enough with the options to spot the issue off the top of my head

[bofia]

@qhenkart Sure, it's mostly the starting template

# Where are all the schema files located? globs are supported eg  src/**/*.graphqls
schema:
  - graph/schema/**/*.graphqls

# Where should the generated server code go?
exec:
  filename: graph/generated/generated.go
  package: generated

# Uncomment to enable federation
# federation:
#   filename: graph/generated/federation.go
#   package: generated

# Where should any generated models go?
model:
  filename: graph/model/models_gen.go
  package: model

# Where should the resolver implementations go?
resolver:
  layout: follow-schema
  dir: graph/resolver
  package: resolver

# Optional: turn on use `gqlgen:"fieldName"` tags in your models
# struct_tag: json

# Optional: turn on to use []Thing instead of []*Thing
# omit_slice_element_pointers: false

# Optional: set to speed up generation time by not performing a final validation pass.
# skip_validation: true

# gqlgen will search for any type names in the schema in these go packages
# if they match it will use them, otherwise it will generate them.
autobind:
  - "<my private repo>/gqlgen-poc/internal/graph/model"

# This section declares type mapping between the GraphQL and go type systems
#
# The first line in each type will be used as defaults for resolver arguments and
# modelgen, the others will be allowed when binding to fields. Configure them to
# your liking
models:
  ID:
    model:
      - github.com/99designs/gqlgen/graphql.ID
      - github.com/99designs/gqlgen/graphql.Int
      - github.com/99designs/gqlgen/graphql.Int64
      - github.com/99designs/gqlgen/graphql.Int32
  Int:
    model:
      - github.com/99designs/gqlgen/graphql.Int
      - github.com/99designs/gqlgen/graphql.Int64
      - github.com/99designs/gqlgen/graphql.Int32

[qhenkart]

@bofia thank you, unfortunately there is zero documentation on the yaml file, and I've been using gqlgen for much longer than most of these features existed.

You will want to remove the resolver section of the yaml file. This autogenerates the resolver in an opinionated way which, as you've noticed, doesn't scale well. Great for a new small project, but not good for what you are trying to do.

You can then create the resolvers yourself (which is really simple and easy), as well as customize them and avoid the auto-generate making a mess of your code

[qhenkart]

what I really recommend for a new project is to keep the auto generate for your first generation. Then removing it. Then you can easily duplicate the generated code in the exact way you want

[iJimmyWei]

Expanding on what @qhenkart said and others had said,

I had an issue of circular imports, so I had to make a few changes (as I needed to pass in my database instance (scylla in my example) to the resolver).

I structured my resolvers in a way like so:

- resolver
--- resolver.go (your root resolver, called in your main.go of your server on runtime)
- mutations/
--- a.go
--- b.go
--- mutations.go
- query/
--- c.go
--- d.go
--- query.go

Resolver.go

package resolver

import (
	"github.com/XYZ/graph/resolver/mutations"
	"github.com/XYZ/graph/resolver/query"
)

type queryResolver struct{ *Resolver }

type Resolver struct {
	DB     *scylla.Client
}

func (r *Resolver) Mutation() generated.MutationResolver {
	return &mutations.MutationResolver{
		DB:     r.DB,
	}
}

func (r *Resolver) Query() generated.QueryResolver {
	return &query.QueryResolver{
		DB:     r.DB,
	}
}

Mutations/mutations.go

package mutations

type MutationResolver struct {
	DB     *scylla.Client
}

Query/query.go

package query

type QueryResolver struct {
	DB     *scylla.Client
}

Then you can hook up your relevant resolvers in each package, for example

Mutations/a.go

func (r *MutationResolver) Login(ctx context.Context, id string, password string) (*models.Account, error) {
	account, err := r.DB.Login(
		id,
                password,
	)

	if err != nil {
		return nil, err
	}

	return &account, nil
}

[bofia]

Thanks @qhenkart and @iJimmyWei. Yep that all makes sense. I was hoping to still be able to utilize the resolver auto-generator, but sounds like that will have to turn off at some point

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

No stale please.

[devdudeio]

imho the structure should be generated per datasource and domain. or the config should be more flexible. I work on GQL Server with lots of types, resolvers and fields and really would like to see something like this:

- graph
-- resolver.go (root resolver)
-- mutations.go (root mutation)
-- query.go (root query)
--- datasources (DataSource could be a REST API, DB, GQL API or any other Service)
----- DataSourceA (eg. REST API)
-------- DataSourceA.connector.go (eg. connects to a REST API, baseURL, caching etc)
-------- DomainA (eg Users)
----------- domainA.resolvers.go (eg. Resolver for Users from a REST API)
----------- domainA.graphqls (User schema)
-------- DomainB (eg. Post)
----------- domainB.resolvers.go (eg. Resolver for Posts form REST API)
----------- domainB.graphqls  (Post schema)
-------- DomainC
----------- domainC.resolvers.go
----------- domainC.graphqls 
-------- DomainD
----------- domainD.resolvers.go 
----------- domainD.graphqls 
----- DataSourceB (eg. PostGres)
-------- DataSourceB.connector.go (eg. connects to a PostGres DB, root/pass etc)
-------- DomainA (eg. Comments)
----------- domainA.resolvers.go (eg. Comments resolver form a Postgres DB)
----------- domainA.graphqls (Comments Schema)
-------- DomainB
----------- domainB.resolvers.go 
----------- domainB.graphqls
-------- DomainC
----------- domainC.resolvers.go
----------- domainC.graphqls
-------- DomainD
----------- domainD.resolvers.go 
----------- domainD.graphqls 

This is more or less my folder structure on a nodejs graphql server implementation. This structure issue is really setting me on hold from using gqlgen for larger projects. I really would like to use it but we consume a lot of DataSources and a domain specific folder structure seems not to be possible with gqlgen. We have like over 400 Types and so also a bunch of resolvers, amount is growing. More Resolvers coming and also more DataSources coming. I cant see how to maintain large projects with these suggestions mentioned above. GQL is not designed to only consume one datasource. its the datagraph over all of your microservices. It stitches them together. That should be visible in the folder structure.

eg. @iJimmyWei suggestion will be fine at the beginning when you start a project but what if you have like 100 mutations and 100 queries files. Its a nightmare to maintain and very messy when there are also other files like tests or some validators/reducers etc.

It would be awesome when the generated resolver will live in the same folder where the schema lives.

[VerzCar]

Is there a way like @dude-awesome described it?