Spike a graphql simulator

[cowboyd]

This spikes a graphql simulator with envelope, express-graphql
playground, and using the starwars schema from the graphql-js examples

TODO

• How is this going to work as plugin?

[jgnieuwhof]

We need to export these from a module since the 'graphql' simulator accepts these options as dynamic imports.

It's a little undesirable to have this example schema in the 'graphql' simulator package itself.

Should we introduce a @simulacrum/graphql-starwars-schema package?

[cowboyd]

Maybe just @simulacrum/graphql-starwars since the simulator actually will run an entire graphql API. The idea being that if you could just do something like:

import { createSimulationServer } from '@simulacrum/server';
import { starwars }  from '@simulacrum/graphql-starwars';

export function createServer() {
  return createSimulationServer({ simulators: { starwars } });
}

[jgnieuwhof]

This store isn't actually used anywhere in-code (we only wire-up / test the simulated store). It does seem to have some value, if only to illustrate the workflow of having a simulated store that matches the shape of the real one.

Any thoughts on whether we should remove this, or leave it here (and maybe add a simple test)?

[jgnieuwhof]

Wasn't entirely sure of the error handling strategy for these simulators; this should probably be improved?

[jgnieuwhof]

@cowboyd - this has been modularized / cleaned up, and now has some test coverage.

not entirely sure where to go from here; we've thrown around some ideas but it'd be nice to converge on something concrete.

[jgnieuwhof]

To give an update on where this is at:

At the current moment, this PR includes a simple graphql simulator. The simulator accepts a schema, context, and scenarios from the consumer, since we can't make any assumptions about the context or scenarios expected by the schema. This means that the work is still on the consumer to ensure that the schema has everything that it needs.

To this end, an example starwars schema has been added, accompanied by a simulated store and corresponding scenarios. The test suite uses the starwars schema to validate the simulator wires things up correctly.

Next steps might include the following:

• Allow consumers to specify which graph entity corresponds with the Person entity to allow the graphql simulator to work in conjunction with the auth0 simulator
• Providing an option to enable dynamic data generation. This would eliminate the need for consumers to provide a simulated store and corresponding scenarios.

[jgnieuwhof]

Notes from a follow up discussion with @cowboyd:

Cross-service entity composition

The 'person' simulator creates people that exist independent of any other services running in simulation. These services need a way to augment their scenario with the entities from the 'person' simulator.

The following solution was discussed:

• Each service should define and manage its own slice of the store
• The 'person' service should publish a function that allows other service to subscribe to the creation of people
• Services should not be able to subscribe to 'person' changes after scenarios have been initialized, since this would represent an unrealistic response to external changes

Store Ergonomics

The starwars simulation store has been created using the low-level store API provided by @effection/atom. This works, but is cumbersome when trying to perform CRUD operations on tabular data.

We should provide an API backed by the store that supports the CRUD operations that services (like the GraphQL service) typically need to perform.

Design TBD.

GraphQL Factories

The GraphQL schema determines the shape and relationships of the entities in the graph. We can use this information to create factories that help scenario authors create and mutate their simulated data.

While the schema can provide the shape of the data, it does not contain the information required to fully generate semantically correct data (ex. given type User { firstName: String } we want to generate a name, not just a string).

We need to either (or both):

• allow consumers to specify generator functions for scalar fields
• use something like https://github.com/google/intermock to auto-determine generator functions based on field names (this uses JSDoc annotations to specify faker generator functions)

GraphQL Dynamic Data Generation

Once we have GraphQL factories we should have the ability to respond to queries with auto-generated data. This can be very useful for rapid prototyping and demos. This should be presented as an option, since there are situations (such as testing) where consumers need to be very specific about the simulation's data set.

Running the GraphQL simulator in this mode would replace the schema's resolvers with ones that respond with dynamically generated data. This has the added bonus of eliminating the need for consumers to specify a simulation context and scenarios.

Auto-generated data should be stable (running the same query multiple times returns the same data).

The generated data should also have relational integrity; that is, entities that have back-references should result in data that also has back-references. Similar to factories this cannot be inferred by the shape of the schema alone; we will need to provide a way for consumers to specify relational cycles.

For example:

# Person.pet <-> Dog.guardian are inverses
# Person.pet <-> Dog.sitter are not
# This cannot be determined without consumer-specific metadata

type Person {
  pet: Dog
}

type Dog {
  guardian: Person
  sitter: Person
}

[cowboyd]

This is a great writeup @jgnieuwhof!

[cowboyd]

@jgnieuwhof I think we should go ahead and merge these in. Can you add the private true to the packages so they don't publish to NPM just yet and we can let it rip?