Feedback + refinements: ember-cli-mirage-graphql

[samselikoff]

Ember CLI Mirage GraphQL is the library that's farthest along in terms of streamlining Mirage + GraphQL usage.

I don't have experience with it but several teams do. The author (@jneurock) also has some ideas for improving it (discussed over here).

Wanted to open this issue to have a place for everyone to chat about it.

• What are next steps?
• What are good integration points for Mirage + libs like this?
• Do we feel confident enough in a @miragejs/graphql lib? (So far miragejs is a "monolith", we don't have any precedent for adapters/plugins.)
• What examples can we share so folks can get going + we can start to identify common patterns?
• I know others (e.g. @dfreeman) have been working with Mirage + GraphQL. What patterns are you using?
• What other APIs could Mirage add to help improve the story?

[jneurock]

Thanks, Sam!!!

Regarding these questions:

• What are good integration points for Mirage + libs like this?
• Do we feel confident enough in a @miragejs/graphql lib? (So far miragejs is a "monolith", we don't have any precedent for adapters/plugins.)

One piece of insight I can provide about the current Ember CLI Mirage GraphQL add-on is that its main export is a higher order function. You pass in your GraphQL schema and a hash of options and it returns a Mirage request handler callback. To me, this means Mirage is already perfect in this area.

In other words, the integration point for Mirage and Mirage GraphQL is already there and I don't see a potential @miragejs/graphql lib as an adapter or a plugin. I'm all ears; though, if there are better ways than the current implementation.

• What other APIs could Mirage add to help improve the story?

I could be wrong but my suspicion is that we'll discover needs from Mirage's API as we leverage it more to automatically fetch records and deal with relationships. These needs are "ifs", though. It could be that we can already do everything we need to with Mirage as-is.

• What examples can we share so folks can get going + we can start to identify common patterns?

I created this video that goes through some basic examples: Ember & GraphQL: A Quick Example. There are also examples in the add-on's dummy app. I could see pulling these examples out into formal documentation. The examples are generic enough, I think, to be shown outside of any Ember context. There are plenty more examples to add, too.

[dfreeman]

Thanks, Sam! I'll echo a lot of what @jneurock has already said.

What are good integration points for Mirage + libs like this?

Since all GraphQL requests go to a single endpoint, a route handler is already pretty much a perfect integration point. Our integration ends up looking a lot like what ember-cli-mirage-graphql does (modulo some TypeScript stuff I'll leave out here):

import { makeGraphQLMirageHandler } from '@salsify/graphql-client';
import OurSchema from 'our-app/our-schema.graphql';

// Generate a handler once up front to avoid redoing the work
// every time we spin up a new Mirage instance
const graphqlHandler = makeGraphQLMirageHandler(OurSchema, {
  // some optional config
});

export default function() {
  this.post('/graphql', graphqlHandler);

  // ...other routes
};

What other APIs could Mirage add to help improve the story?

Nearly everything we wanted API-wise to power this was already available. The only area we had to get a little creative with was introspection of Mirage itself, though it's entirely possible there are public APIs for some things that we missed.

As an example, we ended up writing something like this, which may or may not be relying on an implementation detail and would have been super helpful as just a method on Schema or Db:

function collectionExists(schema, modelName) {
  if (!modelName) {
    return false;
  }

  return camelize(pluralize(modelName)) in schema.db;
}

Do we feel confident enough in a @miragejs/graphql lib?

If you want to provide a GraphQL handler as a first-class piece of the miragejs ecosystem, I think that would be totally reasonable and could build pretty easily on the learnings of ember-cli-mirage-graphql and any other work folks have done to bridge the gap.

Since the integration point is already pretty neat, though, I don't think Mirage itself necessarily has to do much. The main gap I see right now is just the lack of a framework-agnostic implementation. You could probably copy/paste our handler into a vanilla npm package and have it 'just work', though, and I suspect the same is true for the implementation in ember-cli-mirage-graphql.

(So far miragejs is a "monolith", we don't have any precedent for adapters/plugins.)

One thing I realized at some point when working on this was that it doesn't make any use of Mirage's serialization layer at all; it really just relies on Pretender + Mirage's DB/ORM. If you're considering ways to "un-monolith" Mirage, that might point to serialization as something that could make sense as a separate package from the core.