#Erik Sipsma3294 Do you think we ll keep

1 messages · Page 1 of 1 (latest)

analog tusk
#

Actions aren't servers anymore so I don't know if it makes sense to do introspection like that. We could code the action "runtime" to read the schema file and convert it to introspection format before returning it to the server, but that just seems like a more roundabout way of having the server read the schema file from the image and convert it to the introspection format

#

I do think it would make sense to have the actions return the schemas to the server rather than reading it from the image, but I thought that would be in longer term (to support dynamic schemas)

rugged moat
#

Well that could be handled by the SDK and a built-in resolver (e.g. __schema__ or whatever)

I'm wondering what the "correct" format would be. Federation, thunder etc use the introspection JSON format to merge schemas rather than the AST

but I thought that would be in longer term

100%

Only asking because there's a ton of tedious code that goes into AST->graphql-go code which is completely different if we go introspection->graphql-go

graphql-go-tools has that AST->schema code, thunder (and other things that do federation) have introspection->schema

#

rephrasing: deciding which piece of code I'm going to re-use for converting + merging ... the input format affects that a lot, just wondering if we had any particular attachment to one or the other

analog tusk
#

Hm yeah I see what you mean. I would have originally thought that the SDL is a simpler format and therefore preferable: it works now because we just have users write it and then include that file in the imported package plus I would have thought it'd be easier to deal with in the dynamic actions case.

However, even though the introspection output is extremely verbose and seems complicated, it does have the pro of being json and therefore possibly more easy to generate than graphql SDL in that respect?

#

I'm just thinking about the future where someone is trying to write a runtime for ObscureLang that has a json lib but not a graphql sdl lib, so if they have to generate that schema themselves would they prefer to generate verbose but json data or succinct but SDL

#

Summary: I don't know, I'd have to think about it :-), but whatever is easiest to get going is okay for the moment

rugged moat
#

SGTM 🙂

#

Giving it one last try before copy pasting the tools stuff (I'm really not looking forward to that)

With thunder federation, I could maybe trick it into thinking that every single field is federated (so that it attempts to do an individual federation call for each field, rather than send a chunk of the query). Then swap out the federation client to do an execop(resolver)

#

so we should be able to use a "federation server" while still doing one resolver call at a time for caching

# 
// SchemaWithFederationInfo holds a graphql.Schema along with
// federtion-specific annotations per field.
type SchemaWithFederationInfo struct {
    Schema *graphql.Schema
    // Fields is a map of fields to services which they belong to
    Fields map[*graphql.Field]*FieldInfo
}
#

They have this in place where you can actually overlay a list of "services" for each field

#

a service is just a string, they give it back to you in a callback when you need to call said service

#

I'll try a little bit and if it's a no go, then back to the hack-y graphql-go-tools stuff

analog tusk
#

Yeah that sounds extremely intriguing, I can't tell just from that snippet how you deal with subfields (it seems like you provide one map of top level fields), but presumably they must deal with it

#

either way yeah that would be super cool if it works!

rugged moat
#

... it didn't. Going back to the easy path of graphql-go-tools. Made some progress, however realized extend doesn't really work with it (it randomly uses one of the extended definitions as the whole definition)