Resolverless objects about gqlgen HOT 11 CLOSED

I'm hoping to get rid of types.json in favour of schema directives, eg:

type Widget @generate(leaf: true) {
 ...
}

type OtherThing @bind(type: "mycorp.org/models.OtherThing") {
 ...
}

Unfortunately the parser I'm using doesn't currently support them, but thats the end goal. Putting effort into doing more with types.json feels like wasted effort. If an all or nothing cli flag is enough it might be a decent tradeoff until the directives land.

Lots of good reading in the apollo docs, as usual https://www.apollographql.com/docs/graphql-tools/schema-directives.html

from gqlgen.

Have you tried it, It should just work?

type Widget struct {
  Foo string
  Bar string
  Children []Tuple
}

if you create a types.json with

{
   "Widget": "package/for/widget.Widget"
}

from gqlgen.

The introspection objects are all defined this way so only the root query resolvers need to be added to the graph manually.

https://github.com/vektah/gqlgen/blob/master/neelance/introspection/introspection.go

from gqlgen.

Ohhhhh. I didn't realize that's how to hit that codegen path. Trying it now.

So can I flag the model codegen to make the full objects somehow? 🤔 I could do all the types manually like this, but the model codegen is actually already super close to what I want anyway...

from gqlgen.

Holy smokes, I made some other errors declaring my type manually and your error messages were excellent and now it works.

This library is kind of amazing 🎉

from gqlgen.

Perhaps replacing non scalars with an ID isn't as useful as I first thought. Chances are if that ID is useful you would have already created an external database model for it.

I don't really want to break BC, but perhaps a cli switch for inlining nested models and a deprecation warning...

edit:
I guess the problem is if you generate every non scalar field inline you can never go back to a resolver. This would make all generated models terminal leaves in the graph.

from gqlgen.

I think the types.json allowing the user to declare their own types and ask to use them is pretty great. Sometimes I want to use that for some very custom type. Sometimes the generated types (plus children) will fit perfectly though. Why not both? 😄

Perhaps if types.json was a union of options for each type? e.g.

{
  "Widget": {"leaf": true},
  "OtherThing: {"userType": "mycorp.org/models.OtherThing"}
}

or some other way of configuring like this.

This would make all generated models terminal leaves in the graph.

My immediate gut reaction was thinking that should be fine in practice, but maybe I just haven't thought of enough use cases yet. Would config options like the above give us a way to avoid this limit anyway though?

from gqlgen.

Are directives really appropriate? Whether things are e.g. a leaf type like this seems like an implementation detail... and of my server side specifically, not of anything any clients should know about.

I guess if it works, it works, but... I figure I should be able to use the same schema to generate basic compatibility checks and test mocks and such in the client (even in other languages, etc...), so introducing more directives that other tools need to most certainly ignore would seem... odd. My two cents would be that keeping a separate configuration file (like types.json) with these details apart from the schema seems much cleaner.

from gqlgen.

not of anything any clients should know about.

Anything used by the server to generate would get stripped from the introspection api, clients shouldn't see it. Most of the client tools should be generating the schema using reflection, not poking at the file directly. just my $0.02

from gqlgen.

Well, this is not a hill I'm going to die on or anything 😉 but for what it's worth: I replicate the schema file between projects and generate tests in the other repos for CI, offline -- not using the introspection API. I like the offline nature of this. Doing it through introspection would "work" but seems like 10x more moving parts -- I'd have to launch a whole server, configure my other project's tools to aim at that server just to get what should be an almost-identical schema file back out, and automating this would be... cough. Meanwhile, just copying a file between repos, a trivial shell script can check if they're in sync or not, and even do a git bisect in seconds; simple is good.

From the other way... I can't really think of anything that gets better by putting Golang type mapping info -- which is almost definitionally orthagonal to the graphql schema, since language agnosticism was one of the original selling points of GQL -- into the schema file. It just avoids adding another file...? Inodes are cheap :)

from gqlgen.

Yeah, fair points. I'll make sure the current system keeps working.

from gqlgen.