Large type system does not compile. executionContext too large

[magiconair]

What happened?

With very large type systems gqlgen can generate code that can no longer by compiled by the go compiler. Once more than 65.000 field marshaling methods have been added to the executionContext the Go compiler fails with:

<autogenerated>:1: internal compiler error: too many methods on *executionContext: <some number>

In our case we hit that limit at 78.000 methods. We realize that running such a large type system is probably not efficient and also notice that the gqlgen compiler hasn't been optimized for this. It takes quite some time to generate the code because the generation is single threaded. While we are working on refactoring our approach we are blocked by this problem.

There is a simple fix since the majority of the methods on executionContext are field marshaling functions which are all private. Their number grows with the number of types and number of fields per type.

They can safely be converted to regular functions where the *executionContext is passed as an argument. Their names are unique and most likely won't collide with any existing function. And if that would be the case the internal function can be renamed.

In our case the number of methods went down from 78.000 to just 4.200.

We are currently testing this with v0.17.4 and will bump to the latest version soon.

The patch is rather small and can be found here: northvolt@78b1786

I will create a PR once we've moved to the latest released version.

[PatrLind]

Perhaps a related question: I'm having problems with gopls being extremely slow and taking a long time to show code completions, when I'm writing code in my generated graphql package. Also the compile times are quite long. And I only have about 4000 methods in my executionContext.
Will this refactor help with this issue too you think?

[magiconair]

I don't know. The easiest is to try it. This patch should work up to v0.17.10 without change. I've rebased it internally to v0.17.33 but we have to make some changes first.

The change itself is very simple. You can clone this repo and use go workspace files to use it.

go work init
go use .
go use ../gqlgen # your cloned copy of the gqlgen repo

[PatrLind]

Thanks, unfortunately I couldn't test it since there were some compile errors with subscriptions.
ec._Subscription_itemUpdates undefined (type *executionContext has no field or method _Subscription_itemUpdates)
Perhaps the POC doesn't support subscriptions yet.

EDIT:
I was able to manually fix that error in my generated.go by putting the ec as a parameter instead. But then I ran into another issue in the gqlgen code:

# github.com/99designs/gqlgen/graphql/executor
../gqlgen/graphql/executor/executor.go:74:22: cannot use validator.VariableValues(e.es.Schema(), rc.Operation, params.Variables) (value of type error) as *gqlerror.Error value in assignment: need type assertion
../gqlgen/graphql/executor/executor.go:175:15: cannot use err (variable of type error) as *gqlerror.Error value in argument to errcode.Set: need type assertion
../gqlgen/graphql/executor/executor.go:176:29: cannot use err (variable of type error) as *gqlerror.Error value in array or slice literal: need type assertion

EDIT 2:
I was able to fix those errors and test with that. But the performance was still same as before.

[ericmeter]

Hi - I'm experiencing the same issues as @PatrLind here - I am using v0.17.43 and gopls v0.15.2. My codebase's executionContext also has coincidentally about 4000 instance methods, and collaborators on it have really started feeling the pain of slow code completions and slow compiling. There's an open ticket with gopls here golang/go#66699 but I'm wondering if there are any other ideas for fixes in gqlgen to reduce the number of instance methods here?

[PatrLind]

@ericmeter, I think I have since mostly solved my slowness issue. I did this by making sure all my models are in a different package that the rest of the graphql code. This way I think the (huge) generated code doesn't have to be recompiled all the time. Not sure why I had it like this from the beginning, maybe I used some outdated guide when setting it up.

When I look back at my change log this is the change I made:
From:

exec:
  filename: internal/apigw/graphql/generated.go
  package: graphql

To:

exec:
  layout: follow-schema
  dir: internal/apigw/graphql/generated
  package: generated

Some other config directives I use (for reference):

schema:
  - internal/apigw/graphql/schema/**/*.graphqls

model:
  filename: internal/apigw/graphql/model/models_gen.go
  package: model

resolver:
  layout: follow-schema
  dir: internal/apigw/graphql
  package: graphql

[ericmeter]

Thanks @PatrLind! Will look into trying these configs

[ericmeter]

We implemented the above and unfortunately we are still seeing the same slowness, will keep poking around.