Support for in-memory and device data

[josephsavona]

As mentioned in the introductory blog post, we're exploring ways to extend Relay to represent data from multiple sources. These data sources could be in-memory objects, native device APIs, or a (GraphQL) server.

The goal is to allow a unified programming model for accessing all the information relevant to an application - while also retaining a few important invariants:

• Components use GraphQL to describe their data dependencies.
• Given a desired output (e.g. a root container) the framework can statically determine all of the required data inputs (e.g. what to fetch, from where, and in what order).
• Avoid unnecessary re-computation of intermediate or other derived data.

Proposed API

The proposed API for product developers is the same GraphQL fragments that we use today. Products can define a unified schema of all of their data, and query it as you would expect:

fragment Foo on User {
  name,                     # server field
  drafts(first: 10) {       # client-only field
    edges { node { title } }
  }
}

Some considerations here are how to namespace fields & types to avoid collisions between different data sources, the API for registering non-server types, and the API for updating non-server data.

RFC

We'd appreciate your input about possible use-cases for this feature. Some cases that we have considered are retrieving a list of photos via native devices APIs or storing a list of in-progress drafts/edits.

[clentfort]

How pluggable would this be? I can imagine situations where I as a user do not need this extended flexibility.
I'm worried that adding this as a core part of relay bloats the project and makes adoption and maintenance harder (for both users and developers).

I'd propose to bundle this work into a new project: A client-side GraphQL proxy that takes care of analyzing GraphQL queries and can dispatches parts/fragments to individual endpoints.
The custom network layer should be powerful enough to allow this kind of integration!

[josephsavona]

@clentfort Those are natural concerns, thanks for bringing them up! Implementing local state management at the network layer has a number of problems, including the fact that all client data would be duplicated (once at the network layer, once in the Relay cache), it would force local data changes to use the heavyweight Relay.Mutations for what should be lightweight changes (for example, optimistic payloads aren't necessary when you're directly changing the source of truth), and it would prevent a variety of runtime optimizations that are critical in practice. In short: this needs to be in the framework.

I'm worried that adding this as a core part of relay bloats the project

We're confident that this enhancement will have the exact opposite effect: a solid architecture for non-server data sources will actually lead us to modularize the codebase even further.

[clentfort]

Implementing local state management at the network layer has a number of problems, including the fact that all client data would be duplicated (once at the network layer, once in the Relay cache)

This might be true for pure in-memory data but not for any kind of device data which will be stored somewhere else. Having relay manage this kind of data sources adds tons of unneeded complexity!
To eliminate problems with cache duplication it might be feasible to add additional meta-data to responses from the proxy that instruments Relay to not cache data. (Which might be a general cool feature to have for data that should always be fetched from the server.)

It would force local data changes to use the heavyweight Relay.Mutations for what should be lightweight changes (for example, optimistic payloads aren't necessary when you're directly changing the source of truth)

This would require to have at least a secondary API for writing mutations of in-memory data, nullifying some of the benefits of using GraphQL in the first place.
To solve the problem of optimistic payloads Relay could be changed to accept a stream of responses for a request: If a optimistic update is needed the proxy could just generate a response and "send" it to Relay immediately, than gather responses from all its data-sources and pass those on. If no optimistic update is needed because it was only an in-memory change the proxy can generate that answer immediately. (I know this would move optimistic updates out of Relay for situations where the proxy is used, but at the same time the proxy would have more knowledge about how an optimistic update should look like).

It would prevent a variety of runtime optimizations that are critical in practice

Could you elaborate which optimizations?

[josephsavona]

@clentfort thanks for the feedback and ideas :-) We'll be sure to engage with the community about architectural choices via follow-up issues and pull-requests. However, for now I'd like to refocus the discussion on concrete use cases in order to fully define the problem first.

A use case that we've considered is validation of client-only data. For example, when a user creates a draft of a post to a group, it's invalid if they lack privileges to post to that group. In these cases, the validity of the draft is a function of the draft itself (local data) and user/system settings (server data). Further, any change to either input source should ultimately update any views displaying the draft's validity. We've been referring to this as composed state.

Are there other examples of composed state? Is there a need for arbitrary levels of composition, or is data source -> compose -> react view sufficient?

[josephsavona]

cc @vladar who had asked about client-side data in #106

[vladar]

@josephsavona My current case (real world example):

Consider thread of comments. Single comment can be "focused" or not. Focused comment will be highlighted + there is separate non-child component in the sidebar that displays full details about comment author.

So what I need effectively is:

1. Know if currently rendered comment is "focused" to show some outline.
2. Find out currently active thread (there may be many different threads)
3. Receive details about author of focused comment for currently active thread

So this is pretty much transient local state. It must be shared because required by different hierarchies or React components (thread and authorInfo).

Ideally, with Relay-only solution I would write query like this:

query {
  activeThread {
    focusedComment {
      author {
       ...Fields
      }
    }
  }
}

I guess, I would also want to add some directive to query to mark field as local state.

But even if you can implement something like this for querying - there is another question about handing local state transitions. They may require some state transition engine behind them (like Flux store / state reducer).

Also they may be "mixed" - say local state changed when some mutation is executed that also mutates data on the server.

There are indeed many edge cases here.

[ykagan]

A common use case for this would be dealing with non-GraphQL data sources.
We use an on-device service to store data about current device state. The data is pushed to the client via a socket connection. We wind up storing this in Flux stores and then merging Relay data and Flux data in the container, which is fairly error-prone and complex.

Currently we have something like this:

    query {
        app {
          id,
          display_name,
          description
          ...

and:

     AppFluxStore<List<App>>
       App: {id, isInstalled, isDownloading, etc}

In order to render the current app state, we need to resolve the GraphQL query, find the appropriate matching id in the FluxStore, and merge the information together.

One solution would be to have local fields that:

1. have a getter method that can retrieve arbitrary local data based on query results (id in the case above). essentially they can "augment" server-side data with local state once a query is resolved
2. can subscribe to change events in a FluxStore or to arbitrary event emitters.

This would open up a path for relatively easy migration from Flux-based apps to Relay.

[josephsavona]

@ykagan that's a great example of the uses-cases we've looked at. It's common for products to have views that compose server & local data. Validation is another example: item data is local, but rules about validity come from the server.