#They do IoT stuff and so in their
rose portal
Oh nice, yeah I've seen that before but didn't realize they do federation. The use case is cool too.
Do you think it would be possible for us to use it just as a graphql-go replacement, federation aside? Or is it federation only?
floral harbor
That's what I'm trying to figure out
I've hit a few dead ends with graphql-go, so I was looking at alternatives to do stitching
rose portal
Their example is really old, but doesn't have any federation specific stuff from the look of it, seems promising: https://github.com/samsarahq/thunder/tree/master/example
floral harbor
Not really dead ends, but there's no way to go from SDL to code-based types (what I realized yesterday, so we still need -tools). And there's no way to go from Go types back to schema (so we still need to duplicate the core schema). And there's no way to programmatically alter fields (so we still need to do the parse/alter/print/parse)
So basically the current implementation, we can clean up the code a bit, but realistically speaking that's as good as it gets
I think we could avoid the "schema manipulation as a string" by relying on extend, and not mangling the schema
rose portal
The only parsing I can see them doing is here, and they are also using graphql-go for the ast lib: https://github.com/samsarahq/thunder/blob/783eee2f11300e08cde92bafde237434b478113f/graphql/parser.go#L7
Was a very quick skim of the codebase though, could easily be missing more.
Either way, if thunder ends up not helping and we are back to graphql-go, I think we could get away with eliminating the weakest link: graphql-go-tools. It's clearly buggy (I ran into that situation where it outputs an empty typemap but not error again just a bit ago) and it's also not very complicated.
I'm not 100% sure, but looking at how it's implemented it seems like it just calls out to graphql-go NewSchema, which accepts arbitrary Objects. I think that means if we get rid of graphql-go-tools and work with NewSchema directly we probably could avoid the whole parse/alter/print/parse nonsense
I guess that would effectively mean forking graphql-go-tools into our repo, but at this point I'd prefer that over using it as a library like we do now
But obviously the even better scenario would be we can abandon all of that and switch to thunder or one of the other possibilities
floral harbor
Yeah, that was my starting point
But realized the conversion from graphql-go AST back to a graphql.Schema is messy
as in, just tedious, but there's a couple thousand lines of code in graphql-go-tools to do that
but agree, I'd rather fork it
basically 90% of that project is just AST -> Schema conversion
floral harbor
The only parsing I can see them doing is here, and they are also using `graphql-...
But yeah, the missing link is AST->code. I don't see anything in thunder to do that, it's code first (same problem as graphql-go)
The only bits that do that are in thunder/federation, but I don't know how much that is tied to federation
Ah. The best explaination of federation I've seen yet is in thunder's comments
// Executing a subquery
//
// When a subquery is run on a seperate graphql server, we want the subquery to be nested
// on the "_federation" type so that the graphQL server
// For example, if our query like the example below where "allFoos" is a field on service1
// and "name" is a field on service2.
// {
// allFoos {
// name
// }
// }
// When we send the subquery to service2 it should look like the example below
// {
// _federation {
// Foo(id: $id) {
// __typename
// name
// }
// }
// }
// "_federation" becomes the root query that the subquery is nested under,
// "Foo" is the federated object type that we need to refetch,
// and "__typename" lets gateway know what type the object is.
I don't think this is Apollo federation
(not that we care at this point)
rose portal
I got distracted for a bit using sourcegraph to see what other repos out there also import the parser from graphql-go to see if anyone else has solved these problems: https://sourcegraph.com/search?q=context:global+github.com/graphql-go/graphql/language/parser+lang:go+not+file:^vendor/&patternType=standard
There's tons of interesting repos in there, haven't sifted through all of them. An extreme long-shot attempt to find a solution if we are super desperate I guess 🙂
rose portal
I **don't** think this is *Apollo* federation
Yeah it's interesting how many people have solved various variations on this problem!
I guess we are going down the route of having our own variation on a solution catered to our needs. Still would be cool if we find anyone else with caching problems similar to ours that was using graphql (not likely, but who knows)
floral harbor
Yeah. The annoying part is it turns out the graphql go ecosystem is very immature, typescript that's where it's at
beside gqlgen
rose portal
Yeah there's actually a ton of companies doing go graphql servers but outside of gqlgen they don't seem to have really centered around one thing like how apollo is the server in JS/TS land
Have you looked at this one at all? https://github.com/graph-gophers/graphql-go
The Getting started example looks like its exactly what we want maybe
floral harbor
Yeah, unfortunately it's based on go structs (I'm assuming using reflection), and so we can't add resolvers dynamically (same problem as gqlgen)
Unless I missed something
Basically the main logic is here: https://github.com/graph-gophers/graphql-go/blob/master/graphql.go#L47-L57
- Parse the schema
- "Apply resolvers" (attach function resolvers to the schema) by using reflection on the provided type