#for Monday Erik Sipsma3294 Almost done
umbral drift
Q: Is there a reason why FSID and SecretID have different scalar resolvers? Looks like FSID tries to cast from FSID whereas SecretID not, I don't remember why it's needed in the first place
storm nebula
No, I think that's an artifact of the fact that FSID is the descendent of the old FS, which was a scalar but required actual casting.
That's probably the answer to most questions about various odd things: vestigial remnants of the numerous previous iterations.
Looks great though! Will review in detail monday
umbral drift
Ok that’s awesome — in that case I can make a single, common “string scalar” resolver and just reuse it across FSID and SecretID
Less custom code
umbral drift
Once that works the plan would be to create something like a “remoteschema” package with a Load(fs) function that returns a router.ExecutableSchema (so it’s seamless to the stitching code whether it’s core or something remote)
And that’s where we’d stash the remote schema loading, the heuristics to figure out what needs a resolver or not, and the “bridge” code (runtime API). So it’s neatly tucked away
And then finally we can sunset the “api” package, more or less
That would support Filesystem extensions out of the box etc
The only remaining items are 1) does codegen works with extend and 2) support sub-resolvers
umbral drift
==== random idea ====
Ok so we have sub-resolvers (and how do we “map” to them) and we have “resolver detection” (how do we know if there’s a resolver or not)
Brainstorming here, but combining the two, how about:
type Alpine {
build(packages: [String!]!): Filesystem! @handler(“build”)
}
Basically, we force the user to map fields -> resolvers, for every resolver. No heuristics nothing, very explicit
It’s a little verbose however, but it’s very explicit and we don’t need to be “smart”, we just do what the schema says
Extending the idea, but maybe that’s how we get a “clean break” from graphql (since it’s not a server anymore)
Stupid idea just to illustrate what I mean @handler(exec: “build.sh”)
Basically instead of being in a weird spot where there’s a gql schema and not-really-a-server, we say there’s a schema which explicitly states how to bridge outside of graphql
storm nebula
Yes this is what I’ve been imagining too, with the exception that if you define a field that takes arguments it’s optional to explicitly use the handler directive. I wouldn’t consider that to be heuristic, if a field takes arguments it unambiguously needs to be an explicit handler I think. The directive is for cases where you want an explicit resolver for a field that takes no args or to map to a function that has a different name than the field.
That is nice in that it keeps the simple default cases (i.e. current ones where you only have resolvers direct under Query) boilerplate free; our current schemas would actually still be valid. It’s only the more advanced cases that require directives.