Next Steps

[jneurock]

I have the idea to separate this addon into multiple libraries by its logical parts. Those being:

• The ability to automatically resolve types from a given schema.
• Knowing how to fetch data from Mirage based on fields from a query.

My tentative plan is to create a GraphQL auto-resolver library that expects a resolution strategy to be supplied to it and separately a Mirage auto-resolution strategy. The Ember addon would then become a thin wrapper around these two libraries or it would be deprecated.

I see several advantages here:

• A standalone GraphQL auto-resolution library might be useful in another context.
• Separating the logical pieces could mean easier, more focused development of each part.
• Detaching these capabilities from Ember would ensure compatibility with Mirage itself if it were also detached from Ember.

I've already started experimenting with these ideas. As I spend more time working on the separate libraries the implementation details will become more clear. So far, these are my thoughts:

• Resolvers should be used instead of mocks. See Use resolvers instead of mocks? #12.
• An option for custom resolvers should be allowed.
• The auto-resolver should expect the strategy to have callbacks for resolving GraphQL's built-in types, e.g., GraphQLObjectType, GraphQLInterfaceType, GraphQLList, etc.

[jgwhite]

This plan sounds wonderful to me. Some thoughts:

• Are there any existing “auto-resolution” libraries that we can take inspiration from?
• It seems like code-generation is very popular in the GraphQL ecosystem (or maybe just the intersection of Go and GraphQL?) — is this something worth discussing?
• Regarding “Resolvers should be used instead of mocks” — this is music to my ears. Apollo’s mocking behavior has proven to be more of a cost than a benefit as we’ve used it more broadly. Every time Apollo’s random data pokes through it causes some amount of confusion.

[jneurock]

Thanks for the input!

• Are there any existing “auto-resolution” libraries that we can take inspiration from?

I tried to find some but I had no luck. That said, I'm more than happy to check out a project if someone finds something.

• It seems like code-generation is very popular in the GraphQL ecosystem (or maybe just the intersection of Go and GraphQL?) — is this something worth discussing?

I'll be honest, I'm not sure what this means in the context of Mirage. Do you mean generating resolvers, e.g., generating resolvers for mutations? I'm intrigued.

[jgwhite]

Do you mean generating resolvers, e.g., generating resolvers for mutations? I'm intrigued.

Yeah, exactly. Generating a bunch of javascript that implements all the resolvers (for mutations and queries). I don’t really know what the advantage of this is but it does seem to be a popular approach (at least in Go projects).

[jneurock]

Ah, ok. I think it doesn't apply to queries, at least so far, since this addon basically assumes it knows how to fetch anything from Mirage but mutations are another story. This idea might actually be really nice for mutations.

Chad and I were pairing on this addon during the early stages and we actually implemented default mutations. Then we thought about it more and decided mutations were too broad to implement a default. We assumed everyone would basically override our default behavior for most of the mutations.

But... if we could generate a default mutation on demand, this could be really, really nice. For example, at kloeckner.i we have tons of mutations that are basically doing things like: "Create or update a record of type User with an input type called UserInput".

These mutations are super simple and this pattern could be common enough that a generator for this case might be a big time saver.

[jneurock]

I've been looking into this a bit more and have an update...

It seems like I may not need to create 2 separate libraries. graphql-js allows for default resolvers that run whenever there are no resolvers in the schema for a given field or type. The information it supplies to the default resolvers looks like it will be sufficient for getting the right data from Mirage.

I'll experiment more with this approach and see how far I can get. So far, it's looking promising.

Related: In my experimentation I'm dropping usage of mocks for resolvers. I'm also allowing for resolvers to be passed into the options hash. I think this will make the ability to map args and variables to functions redundant.

This approach would also change how mutations are expected in the options. Instead of mutations having their own key in the options, they would be added to the resolvers. I'm thinking backward compatibility should be fine and the old options should be dropped in 1.0.