#al1000 started by just seeing what

1 messages · Page 1 of 1 (latest)

thorn root
#

It understands extend but the problem is that a schema like this:

extend type Query {
  alpine: Alpine!
}
type Alpine {
  build(pkgs: [String!]): Filesystem!
}

results in an implementation stub like this being generated:

func (r *queryResolver) Alpine(ctx context.Context) (*Alpine, error) {
    panic("not implemented")
}

gqlgen won't generate methods for subresolvers unless explicitly configured to do (even if the fields take args, which makes no sense to me): https://github.com/99designs/gqlgen#using-explicit-resolvers

Explicitly configuring that is not straightforward to put in our generic tool, but even if we did here's what the generated code ends up looking like:

func (r *alpineResolver) Build(ctx context.Context, obj *Alpine, pkgs []string) (*dagger.Filesystem, error) {
    panic("not implemented")
}
func (r *queryResolver) Alpine(ctx context.Context) (*Alpine, error) {
    panic("not implemented")
}

I'm looking to see if there's anything else configurable, but I'm suspecting we may need to either:

  1. Continue doing some schema mangling for now
  2. Customize our gqlgen plugin even more
  3. Move away from gqlgen entirely, replace with the language agnostic tool we've talked about

Gonna start with 2. above just to see if we can get away with anything quickly.

long kiln
#

I think it has something to do with model binding

#

by default, it just assumes everything is a model (e.g. the whole Alpine is a type)

#

so uhm, I think for instance of auto binding is enabled, it will assume that if it doesn't find a model, then it should generate the resolver

#

(don't remember the specifics, but it was working out just fine in the core-gqlgen branch)

thorn root
#

Yeah I tried playing around with model binding settings, but couldn't get it to skip trying to define Alpine(...).

long kiln
#

(sorry on a call)

#

it's per .schema file

thorn root
#

No worries, I just wanted to see if you had any ideas quick, yeah I was just trying per schema to see if it made a difference

long kiln
#

for instance, for those it decided to have resolvers on its own

#

(i don't have a single "force resolver" in that branch and it turned out ok)

thorn root
#

(For when you're free)

Gave the follow-schema plugin a try w/ alpine but still wasn't getting the expected behavior. So I went back to the branch you linked to and tried it there.

Do you remember how you set up this model directory? https://github.com/dagger/cloak/tree/core-gqlgen/core/model

The autobind setting in your gqlgen.yml which points to that dir seems to be key; when I unset that I go back to the behavior I'm seeing w/ alpine where no methods for subresolvers are generated.

The problem is that I can't figure out how this gets bootstrapped. I tried:

  1. Delete all the go files, including model and generated, leave only a server.go with go generate command at top, nothing else
  2. Run go generate server.go
    • That errors out saying that github.com/dagger/cloak/core/model doesn't exist
  3. Unset the autobind key in gqlgen.yml
  4. Run go generate server.go again, succeeds now
    • However, it does not have the subresolvers, same problem as alpine before.
  5. Re-add the autobind key to gqlgen.yml
  6. Run go generate server.go again, errors out with unable to load github.com/dagger/cloak/core/model
    • There are contents in model before this command, it seems like they get deleted and then it errors out?
#

Was there a magic incantation to get this working before?

long kiln
#

hey sorry just saw this

#

ah crap, maybe the magic step in the bootstrap is that I did define a model to start with IIRC, but with almost nothing inside (I think it was Filesystem with ID)