Decouple the service stores

[jgnieuwhof]

Motivation

The Auth0 store is currently coupled to the 'person' simulator, in that it uses its scenario and reaches directly into its slice of the store.

Ideally services should play within their own slice of the store, and should respond to other services with effects.

Approach

This took a bit of exploration to come around to a final design. I started by having the simulation define a slice of the store for each service, so that each service literally only has access to its own store. This created more harm than good; it created divergent data access patterns since scenarios still require access to the entire store.

So, the final approach.

The 'person' simulator now exports an onPerson helper that allows other services to subscribe to changes in its store. Services may specify effects that leverage the onPerson helper to mutate their store accordingly.

To that end, the Auth0 simulator now defines its own auth0 store, with nonce and users substates. It does this via a records helper that introduces some strong-typing to improve the ergonomics of working with its store. A createUserFromPerson effect has been introduced that will create an Auth0 user in response to the person scenario being called.

Similarly, the GraphQL simulator now has a createHumanFromPerson effect that does the same thing.

A simulator's effects now accepts two arguments: store and faker. This enables effects to leverage scenarios in response to events such as onPerson.

One more thing to mention. In my earlier exploratory work I modified services to be an object-y piece of state, rather than an array. This makes it significantly easier for a service to access its own metadata (such as its url). The trade-off there is that the createSimulation resolver now is responsible for transforming that piece of state to a list. I like this, but readers may not; happy to revert this change if it's not desired.

[cowboyd]

One more thing to mention. In my earlier exploratory work I modified services to be an object-y piece of state, rather than an array. This makes it significantly easier for a service to access its own metadata (such as its url). The trade-off there is that the createSimulation resolver now is responsible for transforming that piece of state to a list. I like this, but readers may not; happy to revert this change if it's not desired.

I like this @jgnieuwhof, and in fact, on the client, we should probably convert that list back into a record instead of working with it as a list there.

[jbolda]

The work here is stale and our implementation has drifted. Closing and we can open up a new PR in the future if this is still required.